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

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

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/

Received on Thursday, 24 April 2003 10:40:11 UTC