Re: Suggestions for rdf:List and a value type shorthand

On Aug 23, 2011, at 24:21 , Niklas Lindström wrote:

> 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]).

I agree that binding this to <ul> and <ol> would not be a good idea. It is too restrictive. (We may use shorthands in the case of <ul> and <ol>, but let us look at that later.)

Before going into the alternatives, I would also like to know what your problems are with [1]. I understand there are may be problems (surely there are), but you do not really touch that in your mail below. I still look at [1] as a viable alternative. See also my remarks at the end.

> 
> 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.

I think this is really confusing because, as you say, this is not a datatype _at all_. I am against that type of confusion, hence this approach.

> 
> 
> ## 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).)

There is the issue of @resourcetype that you address below, and I decided to react on it more generally in a separate thread because this is not (necessarily) bound to the list issue.

But it is not clear to me. As I say in the other mail, 

<span rel="dc:hasPart" resourcetype="bibo:Book">....<

would have to lead to a drop of resourcetype, because there is no explicit resource (and hanging rel). On the other hand, it makes sense for a List to generate a blank node as a resource, in fact, that is the usual way lists are used. Ie, there are lots of special cases in the treatment of resourcetype in general that makes this a bit shaky...

> 
> 
> ## 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)...

Merging a datatype and a resource type into one would be very strange and confusing.

An additional issue: I know we are heading (though not decided!) toward an incompatibility with RDFa 1.0. However, I would like to keep such incompatibilities to the strict minimum. Deprecating @datatype for this reason seems to be way beyond what we should do in my view.

> 
> (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.

See separate mail for that.

> 
> 
> ## 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 think I disagree. One of the biggest issues in RDF/XML's list management, in my view, is that it cannot handle lists of literals. I think if we cannot encode things like author's list properly, then we have failed.

So... sorry Niklas, I do not see why your alternatives would be better than the ones in [1]. You operate with magic types; [1] operates with magic resources... Also, as I say in [1], I think tying it to the real rdf types rdf:List may be wrong: in some cases the author may want to control exactly what and when goes to a list and an automatism would get on his/her way. Hence my usage of the pseudo resources ::List or ::member.

That being said: using pseudo resources is not really nice either. The reason I chose them is because I did not want to introduce new attributes. However, if we want to go down the management of lists then, well, why do not we make it clear that we _are_ talking about lists (as Jeni proposes)? So something like

<span rel="dc:creator" resource="::Seq">
     <span property="::member">Grigoris Antoniou</span> and
     <span property="::member">Frank van Harmelen</span>
</span> 

could be replaced by something like

<span rel="dc:creator" container="sequence">
 <span member>Grigoris Antoniou</span> and
 <span member>Frank van Harmelen</span>
</span>

<span rel="dc:creator" resource="::List">
     <span property="::member">Grigoris Antoniou</span> and
     <span property="::member">Frank van Harmelen</span>
</span> 

<span rel="dc:creator" container="list">
 <span member>Grigoris Antoniou</span> and
 <span member>Frank van Harmelen</span>
</span>

This is not fully o.k., because it is not clear whether the member should be a literal or a resource (the same old issue with @rel and @property...); in the original solution I used @rel="::member" and @property="::member", ie, I fell back on the @rel and @property behaviour. So maybe we will have to have @member_property and @member_resource or something like that. Or, again as an alternative, we could say @member="literal" or @member="resource", with a default (eg, member in HTML5 or member="" would mean literal member). Or we could be even more restrictive (after all, this is a shorthand) and

<span member resource="some:thing">balbal</span>

would automatically be a resource (by virtue of resource being explicit) and a literal otherwise.

Cheers

Ivan

> 
> [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
> 


----
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 Tuesday, 23 August 2011 09:49:44 UTC