- From: Ivan Herman <ivan@w3.org>
- Date: Mon, 07 Sep 2009 11:00:03 +0200
- To: Niklas Lindström <lindstream@gmail.com>, Toby Inkster <tai@g5n.co.uk>
- CC: RDFa Developers <public-rdf-in-xhtml-tf@w3.org>
- Message-ID: <4AA4CB93.3090108@w3.org>
Niklas, Toby, I think Niklas is absolutely right: rdfs:member has a well defined semantics and reusing this may lead to triples that are not warranted by the formal semantics of RDF. I think we should keep away from that. I did experiment with list generation at some point and I took a different approach. My approach was to say <ul typeof="rdf:List"> .... </ul> and then the <li> elements could create the specific list elements (I can dig the details out for the specifics). Obviously, the same held for <ol> and, if the type is set to rdf:Seq and co., then those containers are used. If there is a more general interest for this, I can write it down in more details. (I actually got it implemented...:-) This approach is not optimal either, because it is really bound to the specifics of HTML. Ivan Niklas Lindström wrote: > Hi Toby! > > I certainly like this (something for lists is indeed missing). > However, I'm unsure of the appropriateness of using rdfs:member for > the rdf:List relationship. It sounds quite natural, but as I read the > RDFS spec [1] it is only used as a superproperty of the (funny) > rdf:_1, rdf:_2, ... rdfs:ContainerMembershipProperty instances. > > Thus, from an RDF/RDFS semantic point of view I find any relationship > between the rdf:List and the chain of rdf:first members to be > undefined. To interpret a direct relation via rdfs:member seems > reasonable, but can the RDFa spec take such an authoritative approach? > > And regardless, it should be defined whether the statement declaring a > direct relation via rdfs:member should be retained or discarded with > these rules. Keeping them seems superfluous, discarding them won't be > backwards-compatible with RDFa 1.0 processors. (Unless, perhaps, the > rdfs:member could be inferred, and RDFa 1.1 was allowed to do this > "refining inferencing" step. But this is a tricky territory.) > > It may be useful to study how the SPARQL WG is tackling the lack of > rdf:List (and rdfs:Container) support in SPARQL 1.0. See e.g. [2] and > [3]. > > As you also speculate, perhaps a specific attribute for this would be > the cleanest solution (such as @collection="rdf:List", with an > algorithm along the lines of hanging rels for picking up members). > > [1] = <http://www.w3.org/TR/rdf-schema/#ch_member> > [2] = <http://www.thefigtrees.net/lee/sw/sparql-faq#transitiv8> > [3] = <http://www.w3.org/2009/sparql/wiki/Feature:AccessingRdfLists> > > Best regards, > Niklas Lindström > > > > On Sat, Sep 5, 2009 at 5:40 PM, Toby Inkster<tai@g5n.co.uk> wrote: >> Justification: >> >>> Yes, rdf:Lists are truly horrible in RDFa. In fairness to RDFa, they're >>> just a very complex structure and are horrible in a lot of RDF >>> serialisations - N-Triples, TriX, RDF/JSON, etc. The only serialisations >>> where they seem reasonable are those that provide syntactic sugar to handle >>> them - e.g. Turtle and RDF/XML. >> >> The following language in a future spec would make marking up lists in RDFa >> much easier: >> >> """ >> RDFa 1.1 processors MUST handle the property rdfs:member specially. If the >> subject of a triple with predicate rdfs:member is known to be an rdf:List, >> then the processor MUST add appropriate rdf:first, rdf:rest, and rdf:nil >> triples to assemble the list. If the subject of a triple with predicate >> rdfs:member is known to be a rdf:Bag, rdf:Alt or rdf:Seq, then the processor >> MUST add appropriate rdf:_1, rdf:_2, etc triples. >> >> "Known to be" = RDFa processors MUST recognise the explicit container types >> rdf:List, rdf:Bag, rdf:Alt and rdf:Seq. RDFa processors MAY implement RDFS, >> OWL or other reasoning to determine that other resources may be containers. >> """ >> >> There are of course other ways this could be handled - via an additional >> attribute for instance, or by triggering particular behaviours based on >> <ol>/<ul> elements. (Though the latter has the disadvantage of not >> translating to non-(X)HTML languages very easily.) I'm not wedded to the >> solution above, but I'd like to see better rdf:List support in RDFa 1.1. >> >> -- >> Toby A Inkster >> <mailto:mail@tobyinkster.co.uk> >> <http://tobyinkster.co.uk> >> > -- Ivan Herman, W3C Semantic Web Activity Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 PGP Key: http://www.ivan-herman.net/pgpkey.html FOAF: http://www.ivan-herman.net/foaf.rdf
Received on Monday, 7 September 2009 09:00:41 UTC