Properties that change meaning depending on context

Jason, team

Here is the discussion from RDF-interest on properties that change meaning
depends on context. This discussion came from CC/PP. 

From Mark Butler:
>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
>
>
>Dr Mark H. Butler
>Research Scientist                HP Labs Bristol
>mark-h_butler@hp.com
>Internet: http://www-uk.hpl.hp.com/people/marbut/
>

From Graham Klyne: 
=======================================

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

From Patrick Stickler:

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: LYNN,JAMES (HP-USA,ex1) [mailto:james.lynn@hp.com]
Sent: 16 April 2003 15:13
To: 'Patrick.Stickler@nokia.com'; 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 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: 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

-----Original Message-----
From: Butler, Mark [mailto:Mark_Butler@hplb.hpl.hp.com]
Sent: Thursday, April 24, 2003 10:38 AM
To: 'LYNN,JAMES (HP-USA,ex1)'; 'Patrick.Stickler@nokia.com';
GK@ninebynine.org; Butler, Mark; www-rdf-interest@w3.org; www-di@w3.org
Subject: RE: Should the meaning of properties change dependent on struct
ure? ( was CC/PP components)

Mark Butler:
Hi James, Patrick, Graham

Firstly thanks for your comments.

> -----Original Message-----
> From: LYNN,JAMES (HP-USA,ex1) [mailto:james.lynn@hp.com]
> Sent: 16 April 2003 15:13
> 
> <snip>

So to ask a subtly different question when we have two properties that are
aimed at different domains are we best creating separate properties and
relating them using something like RDFS or should we define them as being
the same? In my previous post, the example I gave was should we just use
expirationDate for pageExpirationDate and creditCardExpirationDate or should
we distinguish between them? Which is better modelling practice? 

The problem is often even though values seem to have the same semantics,
often we process those value in different ways and the nature of the
processing implies some semantics. Michael Stonebreaker gives a good example
of this in the introduction to his book on object relational databases.
Apparently when a well known database started to support dates as a
datatype, they received a very irate call from a programmer working on an
application for bond markets. Apparently certain bond markets (I think the
NYSE but I'm not sure) pay bond returns as if the year was broken up into 12
equal months in the year whereas over bond markets pay returns based on
working days. So when you used the functions the database supplied for date
gave the wrong answers for this bond market. So does date have a different
semantic here or not?

My guess is we are probably better using the scheme Graham suggests i.e.
define separate properties and then map between them? So we can still
determine properties are related, but if we need to distinguish between them
when we identify subtle differences in semantics we can do?

Also I suspect James' example of green is slightly misleading, as I'd class
green as a property value not a property. So this is more like the kind of
thing defined in a controlled vocabulary, and it is likely that several
different properties might adopt the same controlled vocabulary? 

What do other people think?

Dr Mark H. Butler
Research Scientist                HP Labs Bristol
mark-h_butler@hp.com
Internet: http://www-uk.hpl.hp.com/people/marbut/

Mark,

You are correct, I was sloppy in calling green a property rather than a
property value. Similarly, behavior is affected not by the ExpirationDate
property but by its value. So, I don't think it weakens the analogy, but
thanks for correcting me. the last thing we need is to introduce even more
ambiguity into these discussions.

In general, I think it is best to keep things simple and use the same
properties everywhere whenever possible, especially for some core vocabulary
(no, I have no idea what these properties are). Certainly there is a
potential danger here, and perhaps that should be part of the criteria for
creating specific properties and I think this is what everyone seems to be
saying.

James

At 15:38 24/04/2003 +0100, Butler, Mark wrote:
>So to ask a subtly different question when we have two properties that are
>aimed at different domains are we best creating separate properties and
>relating them using something like RDFS or should we define them as being
>the same? In my previous post, the example I gave was should we just use
>expirationDate for pageExpirationDate and creditCardExpirationDate or
should
>we distinguish between them? Which is better modelling practice?
>
>The problem is often even though values seem to have the same semantics,
>often we process those value in different ways and the nature of the
>processing implies some semantics.

I suspect there's often going to be an element of judgement about 
this.  The case outlined here suggests to me that different properties 
would be appropriate, so that processing can easily be directed based on 
the property alone.  In other cases, where a property may be used in 
different contexts but processed similarly, I think a common property may 
be easier.

#g


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

Received on Friday, 30 May 2003 12:25:32 UTC