Re: Should the meaning of properties change dependent on structure? ( was CC/PP components)

My take would be that, while allowed, CC/PP "chameleon" attributes should 
be deployed only with great care.  Whether a property is usefully re-used 
over different component types is, I think, a function of how you expect 
the property to be treated.

(I noted the following in the CC/PP change log.  I couldn't find any text 
recommending that properties on different components be distinct, though I 
thought that had been left in:

20010510  [...] Remove requirement for an attribute to be unique across all 
components of a profile. [...]   ).

For example, your example of "CreditCardExpirationDate" and 
"SessionExpirationDate" sound to me like rather different properties with 
possibly different treatment, and would probably better be given separate 
attribute URIs.  But I can also imagine properties that mean pretty much 
the same thing wherever they appear (e.g., a component definition 
expiration date) where the same property might usefully be applied to 
different components with broadly the same meaning.

 From a theoretical point of view, RDF can support either approach -- the 
property defines a relation over subject/object pairs -- though in some 
circumstances I think there may occasionally be some unexpected conclusions 
if the same property is used to have different meanings with 
different   subjects.  For example, suppose we have an ExpirationDate 
property used to the end of a credit arrangement, and also the time by 
which a transaction using a given session must be completed;  what is the 
meaning of this property if applied to something that is both a credit 
arrangement and a session?  In this case, using a single property, one 
cannot assert one meaning without also asserting the other.

If in doubt, my recommendation would be to use different property URIs, 
noting that they can be declared to be subproperties of a common property 
if there is subsequently a desire to reflect any common features.   (Though 
this latter option presumes some level of RDF schema processing.)

#g
--

At 12:47 14/04/2003 +0100, Butler, Mark wrote:

>Hello RDF-interest
>
>I have a question about the best way to model properties in RDF.
>
>In CC/PP, an application of RDF, there is the concept of components. CC/PP
>properties are grouped into these components e.g. hardware component,
>software component etc. For more details of this see
>http://www.w3.org/TR/2003/WD-CCPP-struct-vocab-20030325/
>
>However this leads us to a question about best practice when modelling data
>with RDF:
>1. Is it better to have properties change their meaning dependent on where
>they are in a profile structure
>2. or is it better for properties to have a single unambiguous meaning?
>
>Daniele Riboni is proposing a vocabulary with a property called
>"ExpirationDate". This property would change in meaning depending on whether
>it is in the CreditCard or Session component i.e. adopt approach 1. However
>Daniele is not sure if this is legal in CC/PP (see forwarded email below).
>Currently it is legal, but not recommended. The alternative would be to have
>two separate properties e.g. CreditCardExpirationDate and
>SessionExpirationDate.
>
>Art Barstow has suggested that if CC/PP should allow approach 1 and if it
>does not then it is broken.
>
>Please can you advise us on the best way to model this i.e. whether approach
>1 or 2 is preferable? If you send your emails to me as well as rdf-interest,
>I will summarise them and send the summary to the DI working group?
>
>thanks in advance
>
>(Stephane Boyera - please can you copy this to the original poster as their
>email address was ommitted in the email you forwarded - thanks).
>
>Dr Mark H. Butler
>Research Scientist                HP Labs Bristol
>mark-h_butler@hp.com
>Internet: http://www-uk.hpl.hp.com/people/marbut/
>
> > -----Original Message-----
> > From: Art.Barstow@nokia.com [mailto:Art.Barstow@nokia.com]
> > Sent: 14 April 2003 12:06
> > To: www-di@w3.org
> > Cc: boyera@w3.org
> > Subject: RE: FW : CC/PP Components
> >
> >
> >
> > Hi,
> >
> > If CC/PP does not permit an Attribute (e.g. ExpirationDate) to
> > be in different Components (i.e. CreditCard and Session) then
> > it seems to me that CC/PP is broken.  (RDF itself certainly does not
> > care.)
> >
> > So the answer to your question is "yes, just do it".
> >
> > BTW, when your schema is publicly avialable, please post the URI
> > to this list
> >
> > Regards,
> >
> > Art Barstow
> > ---
> >
> >
> > -----Original Message-----
> > From: ext boyera stephane [mailto:boyera@w3.org]
> > Sent: Monday, April 14, 2003 4:06 AM
> > To: www-di@w3.org
> > Subject: FW : CC/PP Components
> >
> >
> >
> >
> >
> > --
> > Stephane Boyera         stephane@w3.org
> > W3C                             +33 (0) 4 92 38 78 34
> > BP 93                           fax: +33 (0) 4 92 38 78 22
> > F-06902 Sophia Antipolis Cedex,
> > France
> >
> > -----Original Message-----
> > From: www-mobile-request@w3.org
> > [mailto:www-mobile-request@w3.org] On Behalf Of Riboni
> > Sent: Friday, April 11, 2003 5:32 PM
> > To: www-mobile@w3.org
> > Subject: CC/PP Components
> >
> >
> > Hello everyone,
> > I am considering the possibility to extend the CC/PP
> > framework by defining a new vocabulary for describing data
> > not covered by UAProf, as personal information and interests.
> > Given the wide range of features covered by this new
> > vocabulary, different attributes with the same name (i.e.
> > "rdf:ID" attribute value) may occur.
> > For example, I could declare two "expirationDate" attributes,
> > one belonging to the "CreditCard" Component and one belonging
> > to the "Session" Component.
> > I think that such an RDF Schema wouldn't be valid, as I would
> > redefine the same resource.
> > Is there a way for defining two attributes with the same name
> > in two different Components of the same vocabulary? If not,
> > what's the utility of Components?
> > Please forgive me if my question is a trivial one, but I'm
> > not an RDF expert!
> > Thank you in advance,
> > Daniele.
> >

-------------------
Graham Klyne
<GK@NineByNine.org>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E

Received on Monday, 14 April 2003 10:26:56 UTC