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

Very good comments, Graham. 

I myself think that having "chameleon" properties would negatively
impact interoperability between CC/PP specific applications and
other RDF applications operating on knowledge expressed using the
CC/PP vocabulary. 

I do not believe that in RDF such "chameleon" properties where their
semantics changes contextually are kosher, and that in non-CC/PP
specific applications, ambiguity will arise if they are used.

I would then strongly reiterate Grahams suggestion that you use 
different properties which each reflect the specific semantics
needed in each case, and optionally relate them with a superordinate
property that reflects the intersection of their semantics.

In any case, the semantics of a property should IMO be globally
consistent.

Cheers,

Patrick

> -----Original Message-----
> From: ext Graham Klyne [mailto:GK@ninebynine.org]
> Sent: 14 April, 2003 16:20
> To: Butler, Mark; 'www-rdf-interest@w3.org'
> Cc: www-di@w3.org; 'art.barstow@nolkia.com'
> Subject: 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 Tuesday, 15 April 2003 02:50:04 UTC