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

> -----Original Message-----
> From: ext LYNN,JAMES (HP-USA,ex1) [mailto:james.lynn@hp.com]
> Sent: 16 April, 2003 17:13
> To: Stickler Patrick (NMP/Tampere); 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)
> 
> 
> 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. 

"Break" may be too strong a word, but RDF does not provide
a way to assign contextual meaning to URIs (that I'm aware
of) and IMO there is a strong built-in presumption that
URIs have globally consistent meaning, such that they always
mean the same thing wherever they are encountered.

If a CC/PP application is going to make a distinction between
the meaning of a property based on context and an RDF-only
application will not make such a distinction (since it can't)
then confusion could arise.

> But if you mean it is problematic to model because it 
> is ambiguous to
> humans, I disagree. 

That's not what I mean.

> 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.

I agree. You're definition of the meaning of ExpirationDate does
not seem to vary contextually. But the original question suggested
it would (not that it was fully clear to me how).

> 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.

Again, no disagreement here.

The question was whether the meaning of a property could be different
depending on its context. My opinion is that it should not.

Of course, that's not to say that what a given application does based
on a given property and value will not be contextual, as your "green
light"/"green lawn" example shows.

Patrick


> 
> 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 Thursday, 17 April 2003 05:29:20 UTC