[OGSA-D-WG] Stab at Glossary Terms

[Allen Luniewski]

Dave,

Comments in-lien below.

Allen Luniewski
IBM Cross Brand Services
IBM Silicon Valley Laboratory
555 Bailey Ave.
San Jose, CA 95141

408-463-2255
408-930-1844 (mobile)


"Dave Berry" <daveb at nesc.ac.uk> wrote on 04/15/2007 03:54:52 AM:

> I think it's vital that we define these terms, because there has 
> been a lack of clarity for a while about the difference between data
> access and data transfer.  The existing definition of data resource 
> (originally from DAIS) doesn't distinguish between these two modes 
> in the way that we do, using source and sink to implicitly refer to 
both.
> 
> Comments inline =>
> -----Original Message-----
> From: ogsa-d-wg-bounces at ogf.org [mailto:ogsa-d-wg-bounces at ogf.org] 
> On Behalf Of Allen Luniewski
> Sent: 13 April 2007 20:22
> To: ogsa-d-wg at ggf.org
> Subject: [OGSA-D-WG] Stab at Glossary Terms

> 
> At today's teleconference we agreed that we needed to firm up the 
> definitions in our glossary of the terms Data Resource, Data Access,
> Data Transfer, Source and Sink.  Currently only Data Resource has a 
> definition taken from the OGSA Glossary) as: 
>         An entity that can act as a source or sink of data together 
> with its associated framework. 
> 
> The confusion that was identified centered on the use of the terms 
> "source" and "sink".  The above definition is using them in a fairly
> generic way while the Data Architecture document uses them to mean 
> the source and sink of data transfers.  Here is stab at defining all
> 5 of these terms.  Once we have agreed on the definitions, we may 
> need to do some minor edits to the architecture document as a result. 
> 
> Data Access: Data access is any mechanism that allows an entity to 
> identify data held by a data resource and receive that data from the 
> data resource. 
> Can I suggest changing "identify data" to "identify a subset of the 
data"? 

Agreed.  Much better.

> 
> I'm also not sure about saying "receive that data", as it may not be
> the requestor that receives the data (i.e. the data may be sent to a
> third party).  Would it work to say "and either return that data to 
> the requestor or to make it available for transfer elsewhere"?  I 
> think Mario had a suggestion for some phrasing that might be better 
> than my attempt here.

I see your point and I agree that this needs to be fixed.  Your suggestion 
works for me.

> Data Resource: An entity that can act as a source or sink of data 
> together with its associated framework.  By source we simply mean an
> entity that can originate data.  And by sink we simply mean an 
> entity that receives data. 
> I'm not comfortable with using source and sink in a generic fashion 
> here and in a more restrictive fashion elsewhere in the document (if
> this is what you are suggesting).  I'd rather just refer readers to 
> the glossary definitions of these terms and make sure that all the 
> entries are consistent.
> 
> An alternative definition that I suggested was, "An entity (and its 
> associated framework) that supports a data access interface, or that
> can act as a source or sink for data transfer", although I'm not 
> strongly wedded to that.

The problem is that in the context of data resource I don't want to tie it 
into data transfer, at least not in the DMI sense of data.  The definition 
should include data that is stored/retrieved directly as a result of a 
call on the data resource's API.  How about "An entity that can receive 
data from a requestor or cause its data to be made available to a 
requestor or a third party denoted by a requestor."

> Data Transfer: A mechanism to move data from a source of data to a sink
> of data. 
> Should we say "copy" rather than "move"?   Should we also say 
> "physically copy" or some such phrasing to distinguish this from a 
> mere renaming within a global namespace?

Yes, definitely "copy".  I missed changing this one when I changed sink 
and source to "copy".  I am okay with physical copy although personally I 
do not see it adding much value to the definition.

> Source: A data resource that contains that data to be copied to a sink 
via a 
> data transfer mechanism. 
> 
> Sink: A data resource that receives the data copied by a data transfer
> mechanism from a source. 
> Currently we use "source" and "sink" to mean interfaces on a data 
> resource.  I think we should make this clear.  We could use the 
> terms to mean both the resource and the interface, provided that we 
> are clear about what we are doing. 

Should we add a phrase along the lines of "A sink is also the interface 
provided by a data resource as part of its participation in a data 
transfer."  And similarly for sink.

> 
> Allen Luniewski
> IBM Cross Brand Services
> IBM Silicon Valley Laboratory
> 555 Bailey Ave.
> San Jose, CA 95141
> 
> 408-463-2255
> 408-930-1844 (mobile)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-d-wg/attachments/20070417/f99969de/attachment.html