Suggestions for rdf:List and a value type shorthand

Hi all!

I'd like to take a stab at the renewed interest in support for rdf:List in RDFa.

I have considered the proposal at [1], as well as the ongoing debate
sparked by (e.g.) Jeni Tennison's post [2] and Ivan's feedback [3].

First off, I (as well) doubt that using <ul> or <ol> would suffice,
since there are many use cases where that markup isn't ideal for lists
(as also discussed in [2]).

Instead, I have three closely related alternatives for your consideration:


## Alternative A: overload @datatype

We can overload the meaning of @datatype so that it works differently
if it has a value of rdf:List. RDFa would then interpret that as a
resource type for a (here anonymous) non-literal node, which "scoops
up" nested resources, just like a hanging @rel does.

Also, if a @rel is present in the same element, it would link the
current subject to this list resource.

Example:

    <ul rel="bibo:authorList" datatype="rdf:List">
        <li typeof="foaf:Person" property="foaf:name">Bilbo Baggins</li>
        <li typeof="foaf:Person" property="foaf:name">Frodo Baggins</li>
    </ul>

Yielding:

  <> bibo:authorList (
            [ a foaf:Person; foaf:name "Bilbo Baggins"]
            [ a foaf:Person; foaf:name "Frodo Baggins"]
        ) .

Since there is already special parsing in place for dealing with
rdf:XMLLiteral in @datatype, this isn't really so far a leap.

Apart from one glaring detail: this is a hack semantically, since it
abuses the semantics of @datatype. In RDF, lists and containers are
*not* literals, so the RDF concept of datatype really doesn't apply.


## Alternative B: add a new @resourcetype

We could also introduce a specific @resourcetype attribute for the
sole purpose of typing the object resource when it is not a literal.
This would be a "companion" attribute to @href/@resource, working just
like @typeof works in relation to @about (including implying an
anonymous resource if there is no @href/@resource).

This should then be defined like above to treat rdf:List as special,
triggering the mechanism described above.

(Some years ago some of us were talking (off list) about adding this
@resourcetype, but came to the conclusion at that time that'd be a bit
too much. We might have a different perspective on it now (for one we
didn't discuss this rdf:List feature).)


## Alternative C: redefine @datatype, or deprecate it and introduce @valuetype

We could define a new attribute called @valuetype (superseding
@datatype) which types the object resource *or* sets the datatype of a
literal depending on if a @property or @rel (but not both...) is
present.

Or actually redefine @datatype to work like this, i.e. @datatype
actually means "the type of the object"... That could be quite
confusing though, since as said, RDF datatypes are specific to
literals. It depends on whether a new attribute or redefining the
meaning of datatype in RDFa is more palatable.

The remaining problem with this option is if @rel and @property are
both present. I'd rather avoid specifying the rules for that case (I'd
rather forbid them both being present)...

(One minor argument in favor of a unification would be that in OWL,
the value of rdfs:range should be a datatype if the property described
(the subject of rdfs:range) is an owl:DatatypeProperty -- i.e. the
value is to be an instance of rdfs:Datatype (e.g. xsd:date). If it is
an owl:ObjectProperty it should be a regular instance of owl:Class.)


## The missing object type feature

With the above, we have touched upon what some consider a missing
feature: the ability to have an rdf:type shorthand for the object.
This takes care of a need some (including myself) have had with
unobtrusively typing a resource in the same element as @rel.

Example:

    <div rel="dc:hasPart" resource="#ch-1" resourcetype="bibo:Chapter">
      <h2 property="dc:title" lang="en">One</h2>

Yielding:

    <> dc:hasPart <#ch-1> .
    <#ch-1> a bibo:Chapter;
        dc:title "One"@en .

Granted, adding "yet another" attribute might be considered to add
even more complexity. Personally I feel that it would clear some
things up though. And it would provide us with means for *both*
rdf:List creation (by special treatment of rdf:List) *and* unobtrusive
typing of the object.


## Remaining

Note that this doesn't address the container types, i.e. rdf:Seq,
rdf:Bag, rdf:Alt. We could of course add support for the RDF/XML
"magic" property rdf:li as well, generating rdf:_1, rdf:_2, etc. as
appropriate. Personally I don't think it'd be worth it though, in part
because one can use rdf:_1 and so on explicitly if one needs to, and
more relevantly since they (containers) are AFAIK legacy concepts.

Finally, this proposal does not enable us to write lists of
*literals*. This is possible in Turtle, but not in RDF/XML. I have
seen some use cases for literals, but I believe the majority of lists
are lists of non-literal nodes (like in OWL). Sure, we could work this
in as well if we really want to, using something along the lines of:

    <ul rel="bibo:authorList" resourcetype="rdf:List">
        <li>Bilbo Baggins</li>
        <li>Frodo Baggins</li>
    </ul>

I.e. the rule would scoop up immediate child elements (or perhaps ones
marked with say empty an @property).


Thoughts?

Best regards,
Niklas

[1]: http://www.w3.org/2010/02/rdfa/wiki/ContainersAndCollections
[2]: http://www.jenitennison.com/blog/node/165
[3]: https://plus.google.com/u/0/112095156983892490612/posts/5bx1gaVXceA

Received on Monday, 22 August 2011 22:22:30 UTC