Implementing S

Prolog (skippable)
------

One of the downsides of being collocated with the chair is that I sometimes
get leant on, perhaps more heavily than other WG members.

Today, Brian is pointing out to me that "I can't live with XXX" is a very
strong statement. Much (all?) of my objections are at the level of "I
seriously don't like" rather than if the WG decides this, HP could not, will
not play ball and follow suit.

An example that Brian gave of a convincing "can't live with" statement would
be: the WG proposes dropping containers, someone says, "No, I have lots of
data using rdf:Seq", or "No, I have an already deployed standard using
rdf:Seq".

So in that vein, one of my many drafts of my "can't live with S" message
started wondering about how choosing S would impact Jena. And I realised I
didn't know, so instead of saying S is unimplementable, I thought I would
ask how to do it.

Overall I fear this message is still rather based on an agressive "S is
unimplementable" belief. Given that Dan says he has an S implementation I am
interested in how we differ in our understanding of what constitutes an
implementation.

===

Content
-------

Jena already provides some API support for datatyping.

(Sorry these URLs will wrap)

http://www.hpl.hp.com/semweb/javadoc/com/hp/hpl/mesa/rdf/jena/model/Literal.
html
http://www.hpl.hp.com/semweb/javadoc/com/hp/hpl/mesa/rdf/jena/model/Statemen
t.html

The Literal interface provides for casting the string label on a literal
node into a variety of Java types. The Statement interface provides for
getting the object of the triple already cast into a variety of Java types.

One possible implementation of S in this framework would be:
 [Strings are strings]
 we deprecate the interface that allows casting strings to other types
 we maintain the Statement.getFloat() etc methods for idiom A.
 In
  _:a <fooA> _:b .
  _:b xsd:decimal.map "100.3" .
  _:a <fooB> "99.5" .
  e.g. getFloat on the first triple returns the value 100.3 whereas getFloat
on the second and third triple triggers an exception.

 Of course the application can always use Java mechanisms to convert the
string values into float values but and range constraint <fooB> <rdfs:range>
<xsd:decimal.lex> . is ignored.


 [Each string is some unique value]
 This appears to be Dan's position, but I must have misunderstood!
 We treat idiom-A as above, but with idiom-B we can apply any range
constraints to trigger a globally unique conversion on a literal node.
 e.g.
 given
 <fooB> <xsd:range> <xsd:decimal.lex> .
 then we can call getFloat() on the literal object of the third triple (or
on the third triple). This has the impact that any future calls to
getString() within the same model on the node labelled with "99.5" (notice
by tidiness there is only one) will fail with an exception. This last
exception is because having at an application level decided that "99.5" is a
float then that is what it is.


 [The same API is used for S-A and S-B, one does the conversion within RDF
datatyping, the other does the conversion in application space]
  In this, the getFloat() methods on statements either operate as above for
S-A, or for S-B get the string and convert it to a float.
  Problems that worry me are what do we make of range constraints in this
last case.
  If we are calling getFloat through a Statement interface then we can
perhaps only consider the range constraints for that statement. If we are
calling getFloat through the Literal interface do we ignore all range
constraints or do we consider all range constraints.
The example I have in mind is the "1984" example.

urn:isbn:0451524934 my:title "1984" .
http://giant-redwoods.org/aTree my:age "1984"
my:title rdfs:range xsd:string.lex .
my:age rdfs:range xsd:integer.lex .

  As I understand it, getInt() on the first triple should fail. But what
about getInt() on the second triple or the literal node itself.



====

I see all three implementations as seriously flawed.
Thus I expect I haven't understood how to implement it.
Please clarify.

Jeremy
-

Received on Monday, 28 January 2002 11:39:39 UTC