W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > September 2002

Re: Some excerpts from AdobeXMP SDK Documentation

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Thu, 26 Sep 2002 11:09:02 +0300
Message-ID: <005b01c26533$f9cfd540$d74416ac@NOE.Nokia.com>
To: "w3c-rdfcore-wg" <w3c-rdfcore-wg@w3.org>, "ext Brian McBride" <bwm@hplb.hpl.hp.com>



[Patrick Stickler, Nokia/Finland, (+358 40) 801 9690, patrick.stickler@nokia.com]


----- Original Message ----- 
From: "ext Brian McBride" <bwm@hplb.hpl.hp.com>
To: "Patrick Stickler" <patrick.stickler@nokia.com>; "w3c-rdfcore-wg" <w3c-rdfcore-wg@w3.org>
Sent: 25 September, 2002 21:23
Subject: Re: Some excerpts from AdobeXMP SDK Documentation


> 
> At 16:14 25/09/2002 +0300, Patrick Stickler wrote:
> 
> 
> >For consideration...
> >
> > From MetadataToolkit.pdf:
> 
> Good idea Patrick.  We needed to do something like this.
> 
> 
> >The method UtilityXAP::CompareTimestamps takes as its arguments two property
> >"paths" (triples) and compares the timestamps represented in their literal
> >objects. This operates directly on the objects, not on any internalized,
> >pre-parsed data structures. I.e the literal objects are presumed to denote
> >timestamps that can be compared as timestamps, not strings.
> >
> >There are also numerous methods for retrieving and storing values which
> >insulate the developer from any concerns about the lexical representation
> >used in the RDF -- i.e. applications using XMP concern themselves with
> >the *values* expressed in the RDF, not the lexical forms of their expression
> >(though there are, of course, lower level methods for manipulating the
> >actual lexical forms themselves, if needed). E.g.
> >
> >MetaXAP::getTimestamp
> >MetaXAP::setTimestamp
> >UtilityXAP::GetBoolean
> >UtilityXAP::GetDateTime
> >UtilityXAP::GetInteger
> >UtilityXAP::GetReal
> >UtilityXAP::SetBoolean
> >UtilityXAP::SetDateTime
> >UtilityXAP::SetInteger
> >UtilityXAP::SetReal
> 
> What we need is an objective test of whether an API implementation is tidy 
> or untidy.  We have agreed a model theoretic test, i.e. does
> 
>    <a> <b> "foo" .
>    <c> <d> "foo" .
> 
> entail
> 
>   <a> <b> _:l .
>   <c> <d> _:l .
> 
> If we could express this directly in the XMP api then your suggestion we 
> would have an objective test.
> 
> We can do this in the jena api.  Given a model with the above triples we 
> can write:
> 
>    model.contains(c, d, a.getProperty(b).getObject())
> 
> In Jena this returns true because Jena is tidy (despite having methods such 
> as getBoolean, getInteger etc).
> 
> Is there a way to express the entailment directly in the XMP api so we can 
> execute the test?

I don't see this as a valid question.  Or at least, not one that
provides an illuminating answer.

Any API that provides for both string-based comparisions and value-based
comparisions will both provide for and not provide for the entailment
you suggest, presuming <b> and <d> have differing, incompatable datatypes
(e.g. string and integer).

The salient feature of the XMP API which IMO suggests a value-based bent,
is that there are numerous access and manipulation functions which are
intended to insulate applications from the details of lexical representation.
I.e., they enable to application to function in terms of values rather
than lexical representations (strings). It is true that one can also access
the actual lexical representations, and thus, your entailment above could
be found to hold. But just because one is able to determine string-equality
of two literal objects does not mean that they were intended to mean the
same thing, or that the API is asserting equality of meaning, rather than
simply equality in the form of expression.

Methods such as UtilityXAP::CompareTimestamps, which parses the lexical
representations into a data structure and deals with variations in 
timezones, etc. that are reflected in the lexical representation, clearly 
show that XMP is comparing values, and not lexical forms. Otherwise, such 
a method would be unecessary. You'd just use strcmp() or the like.

The same is true for the primary access methods for getting values from
literal objects and storing values to literal objects.

Patrick
Received on Thursday, 26 September 2002 04:09:08 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:51:03 EDT