OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [xri] [Glossary] Definition of "Resource" and "Attribute"


Lets be specific about why we are talking about attributes:

CR-6: Permanent Identifiers (resource stays a resource even if attributes
change)
PR-13: Attribute Identifiers (nested attributes? identifying attributes?)
CR-14: Version Identification (identifying versions of attributes)

Does this glossary definition addresss any ambiguity here? Does this
definition clear up what "nested attributes" mean? What is an identified
attribute? Isn't that a resource (any that has identity)?

I'm not saying the definition you have doesn't work - I just want to make
sure it addresses any ambiguity we see in the requirements we've actually
identified.

	-Gabe

> -----Original Message-----
> From: Drummond Reed [mailto:Drummond.Reed@onename.com]
> Sent: Friday, February 28, 2003 12:16 AM
> To: 'xri@lists.oasis-open.org'
> Subject: RE: [xri] [Glossary] Definition of "Resource" and "Attribute"
> 
> 
> Mike,
> 
> Good point, use cases always help clarify terms. In fact 
> here's a good one
> from the IETF ResCap spec
> (http://www.ietf.org/internet-drafts/draft-ietf-rescap-req-01.
> txt) that also
> happens to include its own definition of attribute:
> 
> "An attribute is a named characteristic of a resource 
> identifier with a
> value that is meaningful in the context in which it is used.  
> An example of
> an attribute might be a content type that an email address is 
> capable of
> receiving."
> 
> Note the phrase, "meaningful in the context in which it is 
> used". That means
> the attribute "content type that an email address is capable 
> of receiving"
> is an attribute of the resource "email address". 
> 
> So the use case is that a user agent such as a mail client 
> wants to retreive
> an attribute - the supported content types - of a resource - an email
> address. While the abstract concept "supported content types" 
> could be a
> resource on its own, being able to resolve the abstract 
> concept "supported
> content types" as a resource doesn't do the user agent any 
> good unless it
> wants to know something about the schema of "supported 
> content types" - such
> as the enumerations of MIME types.
> 
> But in this case what the user agent needs is the supported 
> content types of
> a specific email address - joe@example.com. This specific set 
> of supported
> content types supported by joe@example.com can ONLY be 
> identified in the
> context of that specific resource. 
> 
> So maybe I should modify my proposed definition of 
> "attribute" along the
> lines of the one provided in ResCap:
> 
> 	"An attribute is an identifiable characteristic of a 
> resource whose
> value is meaningful in the context of the resource it describes."
> 
> =Drummond   
> 
>  
> 
> -----Original Message-----
> From: Lindelsee, Mike [mailto:mlindels@visa.com]
> Sent: Thursday, February 27, 2003 4:48 PM
> To: 'xri@lists.oasis-open.org'
> Subject: FW: [xri] [Glossary] Definition of "Resource" and "Attribute"
> 
> Drummond,
> 
> I understand the distinction you are making with the definition of
> attribute, but I don't necessarily see the need for it.  
> Perhaps you could
> walk me through a couple of use cases that would make clear 
> the need to
> identify information exclusively in the context of a 
> resource.  I would also
> like you to then show me how that wouldn't be already covered 
> by allowing
> resources to "point" to other resources as "attributes."
> 
> Mike
> 
> > -----Original Message-----
> > From: Drummond Reed [mailto:Drummond.Reed@onename.com]
> > Sent: Thursday, February 27, 2003 3:59 PM
> > To: 'xri@lists.oasis-open.org'
> > Subject: RE: [xri] [Glossary] Definition of "Resource" and 
> "Attribute"
> > (lo ng)
> >
> >
> > Mike (and Gabe before him): good stuff. The main reason I
> > sent that opening
> > salvo was to help folks realize how large an impact to the
> > whole effort even
> > small issues with these core terms have.
> >
> > The second reason is that, while it might seem like the term
> > "attribute" may
> > not be that important, in my experience with both XNS and
> > Liberty, it ends
> > out being very important - almost as important as "resource".
> > Being able to
> > unambiguously and persistently reference an attribute in the
> > context of a
> > specific resource is critical when it comes to security,
> > digital identity,
> > DRM, and many other applications of XRIs.
> >
> > That said, I agree with you, Gabe, and Bernard that we should
> > just stick
> > with the URI spec definition of resource as "anything that
> > has identity" and
> > not try to define it further. It's not worth splitting hairs
> > over whether
> > simple attributes actually have identity outside of the
> > resource that they
> > describe.
> >
> > I think your definition of attribute as " data, metadata or
> > other resources
> > associated with a resource" is pretty close to the mark but 
> the words
> > "associated with a resource" don't quite fully distinguish
> > the two things I
> > think are most important about attributes vs. resources:
> >
> > 1) Attributes are always relative, i.e., they only exist in
> > the context of a
> > specific resource, and
> > 2) A special kind of attribute - an identifier - exists for
> > the special
> > purpose of forming an association with ANOTHER resource (that's our
> > definition of identifier).
> >
> > To capture these two nuances, here's a modification to your proposed
> > definition of "attribute":
> >
> >       Data, metadata or other resources that describe a
> > specific resource.
> > Attributes are always relative to the resource they describe.
> > Identifiers
> > are an attribute of one resource whose purpose is to form an
> > association
> > with another resource.
> >
> > How's that work?
> >
> > =Drummond
> >
> > 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC