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

I'm not sure exactly what you mean by chameleon properties not being kosher.
If you mean that they will break RDF machinery, then that would be a bad
thing. But if you mean it is problematic to model because it is ambiguous to
humans, I disagree. I would claim that the semantics of ExpirationDate means
"a date after which the resource is no longer valid". I'm not talking about
logically valid so maybe this is a case where Valid needs to have two
different URIs. By Valid, I simply mean it is no longer acceptable, trusted,
kosher,... In other words, this key no longer works.  Now one might argue
that my response (or may application's response) to a Session with an
ExpirationDate which has passed is different from that of a CreditCard which
has an ExpirationDate which has passed. But this is behavior, not semantics.
To me this would be like saying we need two different URIs for the color
green because I know to go at a green light, but my green lawn doesn't have
the same meaning to me. The color green hasn't changed, just the context.


Cheers,

James

-----Original Message-----
From: Patrick.Stickler@nokia.com [mailto:Patrick.Stickler@nokia.com]
Sent: Tuesday, April 15, 2003 2:50 AM
To: GK@ninebynine.org; Mark_Butler@hplb.hpl.hp.com;
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)




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 Wednesday, 16 April 2003 10:13:33 UTC