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

Hi all,

The problem was never really coming up with a syntax, since there are
plenty of list elements in HTML. (This was suggested in a telecon a
long time ago, and Ben even wrote up a nice, detailed proposal.)

The problem was in deciding what these lists meant, since at the time
of RDFa 1.0, there didn't seem to be any generally accepted technique
for defining lists in RDF. (I don't mean that there weren't any
techniques...I just mean that of those available, it was not clear
that one was the front-runner.)

If it's clearer nowadays which way lists should be constructed in RDF,
then I think that would be a good place to start -- we should agree on
the generated semantics, and then after that, we can work out how they
might be represented.

Regards,

Mark

2009/9/7 Ivan Herman <ivan@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
>
>



-- 
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Received on Monday, 7 September 2009 09:35:06 UTC