-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jeremy Carroll wrote:
| Benja:
|> How about an optional attribute on the <graphset> element, giving the
|> URI of a stylesheet for transforming plain TriX into the user's prefered
|> syntax?
|
| That's a nice idea ... however I am not wholly convinced mainly
because of
| the difficulties in writing a good RDF/XML serializer (see my WWW2002
paper).
|
| My sense is that the problems of RDF/XML serialization are inherent in
the
| problem of re-expressing knowledge reduced to the lowest common
denominator
| triple format back into something more human friendly
Hmmm.
I think you are mostly thinking of how to nest nodes in RDF/XML? I
haven't tried implementing a nested writer, but it would seem that this
is where most actual choices need to be made. Some other things, like
syntactical sugar for encoding URIs and literals, should be really easy
to implement in XSLT, for example transforming int-typed literals into
<int>...</int>. XML literals would be more of a hazzle because you
effectively would need to implement an XML parser in XSLT, as far as I
can see. :-(
On the next level, you would have rules that eat a couple of triples and
trade them for a node-set that represents one particular node. E.g. it
eats the triples
~ _:a rdf:first x:foo
~ _:a rdf:rest _:b
~ _:b rdf:first x:bar
~ _:b rdf:rest rdf:nil
and returns the following node-set as the representation of _:a:
~ <collection>
~ <qname>x:foo</qname>
~ <qname>x:bar</qname>
~ </collection>
As for nesting, one approach would be not to nest by default, but to
have specific rules for what things to nest. This idea is partly in
response with personal experience with Jena's writer making the output
less readable because things I expect to be on top level are nested (you
acknowledge this kind of convention in your paper). This has actually
lead to me seeing nesting as making things less human-readable instead
of more, although upon conscious reflection I guess when the nesting is
well-chosen it does work.
Finally, as one application I see as quite important, one kind of
transformation could eat certain triples and turn them into the outer
"envelope" for the triples, for example like this--
~ x:Leila a :Person
~ x:Leila :birthyear "1987"
~ x:Rex a :Person
~ x:Rex :birthyear "1988"
~ :birthyear a rdfs:Property
turned into this--
~ <birth:days>
~ <birth:year of="http://example.org/ppl/Leila">1987</birth:year>
~ <birth:year of="http://example.org/ppl/Rex">1988</birth:year>
~ <birth:metadata>
~ <triple>
~ <uri>http://example.org/terms/birthdays/birthyear</uri>
~ <qname>rdf:type</qname>
~ <qname>rdfs:Property</qname>
~ </triple>
~ </birth:metadata>
~ </birth:days>
In other words, allow parts of the graph to be transformed into a
domain-specific XML dialect, the remaining triples being encoded in some
envelope tag inside that message.
This application is the prime thing for which your suggestion -- pushing
a variant serialization needs writing a software tool -- really doesn't
work; the idea here is that anybody can just write two stylesheets and
have their XML language not only be readable, but also emittable as RDF.
Now, thinking about it, even without complicated choices like how to
nest best, the above may be too difficult to implement in XSLT The basic
algorithm would be, "here's a set of rules each of which, if it matches,
eats up a subset of the triples in a graph and returns some XML; apply
each rule until it doesn't match any of the remaining triples." This may
not be reasonably simple to implement in XSLT...
On the other hand, if it *were* possible, I would suggest that using
this mechanism for conceptually simple transformations and leaving only
the hard stuff, like choices about nesting, to code in the RDF writer,
would enable easier growth for special-case purposes -- serializing into
a domain-specific XML dialect; serializing relatively verbose
domain-specific RDF idioms (i.e., when you need to come up with some
complex structure like RDF collections for your domain, which could be
serialized in a more human-readable way; an example would be many OWL
constructs, like rdfs:domain -> rdfs:subClassOf -> owl:Restriction ->
owl:minCardinality etc. for which there would certianly be more readable
ways to express them in dedicated XML).
- - Benja
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFAKpPuUvR5J6wSKPMRAn8PAJ47/wRY6ZLaGgRebo6AWl3dgaCV4QCgisn+
LTTPokwxGU/82ipIJmg+s7o=
=CF/C
-----END PGP SIGNATURE-----