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: Ivan Herman <ivan@w3.org>
Date: Mon, 07 Sep 2009 11:00:03 +0200
Message-ID: <4AA4CB93.3090108@w3.org>
To: Niklas Lindström <lindstream@gmail.com>, Toby Inkster <tai@g5n.co.uk>
CC: RDFa Developers <public-rdf-in-xhtml-tf@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">

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.


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

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