RE: Last call on XLink -> RDF mapping

Ron Daniel wrote:
> Hi,
> I've made another pass over the XLink->RDF draft NOTE.

I have begun to implement this in
(extended links are not yet implemented and I haven't had but scant time to

> Changes:
>    1) I've said that links without an arcrole attribute
>       SHOULD be ignored, but still allow the element type
>       to be used as the predicate. This seems the best
>       compromise between safety and capability.

	i've chosen to use the element type as predicate if arcrole is not present.

>    2) I've added an appendix that provides a simple XSLT
>       stylesheet and Java extension function to harvest
>       simple links.
>    3) Some restructuring to reduce the amount of material
>       that gets duplicated.
>    4) Some edits in the section on Synthesizing XPointers.
>       Gist of that is that implementations MUST synthesize
>       some kind of XPointer (since they have to point into
>       an XML document, there is little else they could do).
>       ANY form of XPointer is allowed, although one that uses
>       the ChildSeq abbreviation is recommended.

	I've added support for ChildSeq, enabled when the param:
explicitPathIndices='ChildSeq'. The reason this deserves at least some
discussion is that the ChildSeq, as well as explicit path indices e.g.
/root[1]/another[3] adds difficulty for RDB RDF stores which now need to
keep track of ordering issues in the XML ... presumably we need to allow for
the generated URI to be dereferenced at a later date. Hence constraints are
imposed on the RDB <-> XML mapping (not a pleasant situation, I imagine, for
those working with triple stores.

	An advantage of the attribute value based localization that I am using as a
default, is that it is not element order dependent (on the other hand you
need to be sure to generate unique sets of attribute values ... this type of
constraint is common in the RDB world).

Jonathan Borden
The Open Healthcare Group

Received on Wednesday, 13 September 2000 09:34:16 UTC