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] | [List Home]


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


Exactly right, Gabe, that's why I've been working to nail down the
definition, because we have several important requirements pertaining to
attributes.

In fact, an offline conversation I had yesterday regarding attribute
requirements illuminated for me precisely why it is important, and as a
consequence suggested the most precise definition of "attribute" yet (at
least within our context of identifiers and identification). To wit:

	"An attribute is any data, metadata, or resource that can be
identified only in the context of a specific resource. Attributes always
express a relative relationship; they exist only in the context of the
resource they describe."

In other words, the issue is not whether attributes can be resources or
resources can be attributes. They can. The defining quality of an attribute
is the *scope of its identification*. What makes it an attribute is the fact
that it can only be identified in the context of a specific resource.

Example: John is a resource. Age is a resource. But John's age can only be
identified in the context of John. Therefore John's age is an attribute of
John.

I hope this definition not only makes attributes clear, but also makes the
requirement for attribute identifiers clear: it can be important
syntactically to identity the scope of an attribute, i.e., the resource to
which it is relative. This would be easy if attributes were flat, but if
they can be nested, then that syntactic delineation of the resource to which
they are relative becomes even more important.

Example: URI syntax delineates attributes from resources using the #
character, i.e., the fragment delimiter. But URI syntax is ambiguous as the
syntax of fragments, says nothing about them being nested, and is mute wrt
versioning. These are all requirements I believe XRI syntax needs to
address.

=Drummond  

-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com]
Sent: Friday, February 28, 2003 11:53 AM
To: 'xri@lists.oasis-open.org'
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] | [List Home]