W3C home > Mailing lists > Public > www-rdf-interest@w3.org > April 2003

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

From: Butler, Mark <Mark_Butler@hplb.hpl.hp.com>
Date: Mon, 14 Apr 2003 12:47:32 +0100
Message-ID: <5E13A1874524D411A876006008CD059F066A1C09@0-mail-1.hpl.hp.com>
To: "'www-rdf-interest@w3.org'" <www-rdf-interest@w3.org>
Cc: www-di@w3.org, "'art.barstow@nolkia.com'" <art.barstow@nolkia.com>

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

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

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
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.
Received on Monday, 14 April 2003 07:49:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:41 UTC