RE: XSLT for literal mapping/conversion

> Three triples
>
> _:a rdf:type r1:date .
> _:a xxx:transform eg:r2-to-r1.xsl .
> _:a rdf:value "4th June 2004" .
>
> We might expect xxx:transform to have semantics along the lines of
>
> "the object of this statement is an XSLT transform that when
> applied to the subject serialized in such-and-such a way gives
> additional triples that are also true."

Which is where the problem is- you want
 _:a rdf:type r1:date .
 _:a rdf:value "2004-06-04" .

but after the transform you've got
 _:a rdf:type r1:date .
 _:a rdf:value "4th June 2004" .
 _:a rdf:value "2004-06-04" .

Which is legal RDF, but breaks the initial constraint that the value of the date is a string literal encoding a date using ISO 8601.

So the semantics must be 'are true instead', or else you have two values, which may well break a cardinality constraint on the r1:date type, and will definately break anything that treats the non-ISO value as ISO 8601 (which is beyond RDF, but still rather important).

> This could constitute a semantic extension to RDF as defined in RDF Semantics.

Yes, a purely additive iterpretation would, but it won't give (what I took to be) the desired result- a triple that says the single value associated with the date is a string encoding the ISO 8601 date, that is compatible with other systems that use the r1:date type. Either the semantics of the transform break monotony, or the presence of the input to the transform isn't compatabile with the constraint that a value of the r1:date is ISO 8601.

> FWIW I agree with Damian that it might be better to hang this off a class.

Yes, and associate the transform with the r2:date class, such that
 _:a rdf:type r2:date .
 _:a r2:value "4th June 2004" .

implies
 _:b rdf:type r1:date .
 _:b rdf:value "2004-06-04" .

or have
 r2:date rdfs:subTypeOf r1:date

and
 _:a rdf:type r2:date .
 _:a r2:value "4th June 2004" .

implies
 _:a rdf:value "2004-06-04" .

or
 _:a rdf:type r1:date .
 _:a r2:value "4th June 2004" .
 _:a xxx:transform eg:r2-to-r1.xsl .

implies
 _:a rdf:value "2004-06-04" .

but adding
 _:a xxx:transform eg:rabbits-to-r1.xsl .
to
 _:a rdf:type r1:date .
 _:a rdf:value "rabbits" .

shouldn't imply the replacement of
 _:a rdf:value "rabbits" .
with
 _:a rdf:value "2004-06-04" .
which is required for the constraint that the value is an ISO 8601 date (assuming the constraint is only applied after transformation).

And unless it also implies that the presence of
 _:a rdf:value "2004-06-04" .
implies the addition of the triple
 _:a rdf:value "the result of applying the transform to ""2004-06-04""" .
and so on, the transform shouldn't be using the same property for input and output.

If there is a non-rdf constraint on the interpretation of a value, then that constraint must be upheld by any subclasses, and adding extra properties shouldn't alter the interpretation of the value. Otherwise, you either break applications, or require non-monotonic transforms. You have a choice then, between non-monotonic transforms that filter the set of triples, or breaking the assumptions in other applications.

If a transform is to be used, then input to the transform needs to be in an indepedent namespace* to the output. This has the side effect that the input value to the transform is not subject to any constraints on the output value, allowing monotonic transforms to be used, not breaking other applications' assumptions, etc.


Pete

* not meant in XML sense, a different property in same namespace is also a different namespace.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

Received on Friday, 4 June 2004 09:58:43 UTC