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

Hi Ivan!

2011/8/23 Ivan Herman <ivan@w3.org>:
>
> 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.)

Agreed.

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

I'm sorry, I should of course have discussed that as well. The short
version is that I'm uncomfortable with the magic pseudo-resource
mechanism. I find it a bit obscure and suspect it would be a cause of
confusion. Especially if there are no other use cases for them, since
then a generic mechanism for lists/containers alone seems rather
costly.

In contrast (although I readily agree with your criticism of my A and
C alternatives) I opted to base the magic rdf:List treatment on the
already existing rdf:XMLLiteral mechanism.

Your considerations in [1] are of course *very* valuable, and I
support a lot of it.


>>
>> Instead, I have three closely related alternatives for your consideration:
>>
>>
>> ## Alternative A: overload @datatype
>>
>> [...]
>
> 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.

I absolutely agree. The only "defense" I had for including this was
that list is a "datatype" in some other senses. But it's not an RDF
datatype, so I'll gladly retract this suggestion.


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

That's a good call. It is a suggestion in and of itself, so let's take
it separately.

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

I'll shall respond in the other thread, but for clarity, I hoped that
this (from above) would explain it: '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).'

Given that, I'd expect that we'd now have a dc:hasPart relation to a
bnode of type bibo:Book, and that that bnode would be set as the
current subject within the span.

(A magic rdf:List value would trigger a more intricate list mechanism
though. I believe it would work just like hanging rels in what it
"scopes up", but with the difference that it would spawn a linked RDF
list instead of repeated triples. Something like that could be the
mechanics regardless of what actually triggers the list mode though.)


>>
>> ## Alternative C: redefine @datatype, or deprecate it and introduce @valuetype
>>
>
> Merging a datatype and a resource type into one would be very strange and confusing.

Yup. I agree. Let's not go here. I retract this suggestion as well.

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

I continue to agree. I tried the waters in that direction, but I
certainly understand why it's not a viable path.


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

I see your point. Admittedly, in this specific case I often retort
with the "but strings aren't authors". But that's unfair, I can
certainly imagine valid use cases for lists of literals. (And many
people use names instead of resource references, due to practical
constraints.)


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

I value your reply and ready analysis of the design and consequences
of my suggestions. My intent was to examine a direction I've
considered, since to some extent it played on existing mechanics
(rdf:XMLLiteral). I hope I didn't cause trouble with A and C though --
I felt that I wanted to express them so that we'd get a feel for the
"good" and "bad" parts respectively.


> 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)?

Yes, I'd certainly be open to this. Whichever way we go we seem to
need to introduce either magic or new syntax. With that new syntax
being new attributes, we may be able to produce something readily
understandable.

(I still leave @resoucetype="rdf:List" on the table for now though,
given the outcome of the other thread.)

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

Interesting. First though, as said, I think containers are legacy, and
can be expressed with existing syntax and terms:

    <span rel="dc:creator">
      <span typeof="rdf:Seq"><!-- or the suggested @resourcetype
beside @rel to avoid this span.. -->
        <span property="rdf:_1">Grigoris Antoniou</span> and
        <span property="rdf:_2">Frank van Harmelen</span>
      </span>
    </span>

It's not very beautiful, but then again, neither are containers IMO.
They are "crude" on the semantic (abstract syntax) level of RDF.

Furthermore, "container" is the name for Seq, Bag and Alt -- their
base class is rdfs:Container -- so I would advice against that name
for the attribute. The RDF list structure OTOH is constructed using
the collection vocabulary [4], so I'd suggest @collection, for lists
alone.

Therefore, we might perhaps combine @container and @rel, like:

    <span collection="dc:creator">
        <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.

Something along these lines is certainly good. Lists of resources have
to be supported as well. Recall the notion I describe above that when
a "list mode" is triggered, I think it should capture resources just
like a hanging rel does, but produce a chained list instead of
repeated triples. For that we have a mechanism in place. (Granted,
capturing both @resource/@href *and* @about might be considered
strange; but that's how it works now. Actually, if we had
@resourcetype, the case for @about might have been rejected, as IIRC
it's mostly needed to be able to use @typeof in conjunction. Ah,
well.)

In fact, we might not need @member to capture literals. Scanning for
literals in list mode could be "greedy", by having it start "consume"
on the first non-whitespace text node it encounters within each
(direct) child element.

Full example of a thoroughly mixed type list:

    <ul collection="ex:stuff">
        <li lang="en">An item</li>
        <li datatype="xsd:boolean">true</li>
        <li><a href="/item/three" property="rdfs:label">Three</a></li>
    </ul>

Giving:

    <> ex:stuff (
            "An item"@en
            true
            </item/three>
        ) .

    </item/three> rdfs:label "Three" .

Of course, I can see that the "greedy" part could be considered too
powerful, and perhaps mixing in the hanging rel power will be too
implicit. So @member might be more obvious for capturing at least
literals, or them all.. That'll leave us with:

    <ul collection="ex:stuff">
        <li member lang="en">An item</li>
        <li member datatype="xsd:boolean">true</li>
        <li><a member href="/item/three" property="rdfs:label">Three</a></li>
    </ul>

(That being member="" in XHTML..). That's very close to your suggestion.


In summary, I agree that a new attribute to enable lists can make
sense. Lists are something people are familiar with, and exposing any
part of the specific rdf:List, rdf:first and rdf:next construct is
reasonably not ideal. (The Turtle design is a good inspiration. Even
RDF/XML has "sugar" for lists.)

Best regards,
Niklas

[PS. I post this without digesting it for a while. I feel that it's an
important issue that I wanted to address immediately. Now I'll have to
get back to the vocabulary mechanics ASAP. (And sleep; work (using RDF
and JSON...)]

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

[4]: http://www.w3.org/TR/rdf-primer/#collections

Received on Tuesday, 23 August 2011 23:28:07 UTC