Re: Some excerpts from AdobeXMP SDK Documentation

[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: 26 September, 2002 13:22
Subject: Re: Some excerpts from AdobeXMP SDK Documentation


> At 11:09 26/09/2002 +0300, Patrick Stickler wrote:
> 
> [...]
> 
> > >
> > > 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.
> 
> Oh, then my question must not have been clear.  You claim that XMP is 
> untidy.  I am asking whether there is an objective test whether an API is 
> tidy or not.
> 
> That is a valid question, right?
> 
> >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).
> 
> I think I see what you mean.  But the question remains, is there a way of 
> expressing the entailment in the XMP API.
> 
> 
> >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.
> 
> Ok, fine - that is the test you are applying.  Could you take a look at the 
> Jena API and tell us what conclusion you reach when applying the same test.
> 
>    http://www.hpl.hp.com/semweb/javadoc/com/hp/hpl/mesa/rdf/jena/model/Statement.html
> 

I would say that Jena is fairly agnostic overall. The single
equality comparison method suggests a syntactic comparison,
rather than a semantic comparision (which is understandable,
given the generic nature of Jena) and the fact that equality
is tested on the entire statement means that Jena has nothing
to say about whether the following entailment holds or not:

IF
   Jenny age "10" .
   Movie title "10" .
THEN
   Jenny age _:x .
   Movie title _:x .

If, e.g., Jena had a comparison method that only compared
the two objects, and allowed different subjects and predicates,
and reflected the above entailment, then I'd say Jena was,
at least in terms of that particular method, taking a tidy
view. But since Jena does not offer such a method, one cannot
tell one way or the other.

Also, the fact that Jena provides a test for syntactic equality
of statements doesn't IMO mean that Jena has a tidy view of
inline literal semantics, only that such comparisons are based
on label equality (the form of expression) and current inline
literal nodes have non-unique labels. If inline literal nodes
had systemID prefixes (e.g. _:x"LLL") then the equals() method
would not have to change any, it still would be comparing the
form of expression (syntactic label equality) and that's really
what that method is all about right, to aid in merging graphs?
Any presumption of semantic equality based on string equal
literal labels is made by the developer, not Jena.

With Jena, applications are free to choose whether they compare 
inline literals as strings or values and what actions to take 
accordingly. Jena doesn't seem to care one way or the other.

The key difference between the value-based access functions
of Jena and those of XMP are that for XMP, they are bound
to particular properties and apply specifically to inline
literals, so developers interacting with the properties of
resources in terms of their property access methods have no
choice about whether to interpret the inline literals as
strings or values -- they are always interpreted as values; 
whereas in Jena, it is up to a developer to decide whether or
not s/he will interpret the literal as a value or a string.

So IMO, Jena is neither tidy nor untidy. It simply provides
access to the graph, and a few useful utility methods for
developers who choose to impose value interpretations
on literals, whether or not those interpretations are licensed
by the MT or not. XMP property methods, on the other hand, impose
value-based interpretations on literals no matter what.

For Jena, to support value-based comparison of literals
(either inline or explicitly typed) one would simply (hah ;-)
need to add a module to Jena which would take two predicate-
object pairs and based on knowledge of supported datatypes
and possibly querying the graph for range assertions would
return either true, false, or undetermined. E.g

  3VBoolean equalValues(predicate1, object1, predicate2, object2);

where 3VBoolean is 3-value-logic result (true, false, or maybe). 
After all, it may very well be the case that a complete value 
comparision was executed and the values were, in fact, not equal 
and hence the result is known to be false. That's different from e.g. 
one of the datatypes not being known or not finding any datatype range 
asserted for one of the literal objects, and thus not being able to 
actual compare two values. That's not false. That's just an 
undeterminable test.

I actually started implementing such a software component, based on
http://www-nrc.nokia.com/sw/RDFL.html, but got waylaid by other tasks.
I hope to get back to it one of these days...

The kinds of generic to semi-generic tools where the tidy/untidy
issue will really show up the most will be in query engines, as to
whether comparisions of values will be syntactical (lexical)
or semantic (value) based. Most folks will be wanting to express
queries in terms of values to compare, not forms of expression,
and one would hope that the RDF itself would provide all the
knowledge necessary to make trustworthy comparisons and that
nothing would remain hidden or implicit in application specific
semantics.

Patrick

Received on Thursday, 26 September 2002 08:10:21 UTC