W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > September 2009

Re: Feature request for RDFa 1.1 [Fwd: rdf:Lists in RDFa?]

From: Niklas Lindström <lindstream@gmail.com>
Date: Sat, 5 Sep 2009 22:15:59 +0200
Message-ID: <cf8107640909051315u5f0c9193x63ca24c2c6e768a4@mail.gmail.com>
To: Toby Inkster <tai@g5n.co.uk>
Cc: RDFa Developers <public-rdf-in-xhtml-tf@w3.org>
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

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>
Received on Saturday, 5 September 2009 20:16:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:33 UTC