Re 2: Attempt for a List specification in RDFa (ISSUE-106)

Jeni et al,

To work out the alternatives, I have tried to spec what we discussed in:

http://www.w3.org/2010/02/rdfa/wiki/JLists

and I actually implemented it in pyRdfa (I mean on the version on my machine). I will refer to this version as Jeni's version:-)

For the good order, I have also implemented the 'triggered' version:

http://www.w3.org/2010/02/rdfa/wiki/Lists

I must admit that I may be sold now to Jeni's version. Although it is more restrictive (at least the way I spec-ed it), it is probably true that it makes the 80/20 cut as far as possible us cases are concerned. Because it operates on the collection of nodes on the same level its implementation is also a little bit more simple. For example, although I described in terms of a DOM transformation, I could imagine that Jeni's version is more easily implementable in a streaming environment, because it does not require to run up and down the DOM tree; the full, 'triggered' version may be more difficult in this respect.

(Note that we do not have a decision whether we _do_ add a list generation into RDFa 1.1.)

Ivan


On Aug 26, 2011, at 12:15 , Ivan Herman wrote:

> Hey Jeni,
> 
> (I have added the tracker's issue reference to the subject. B.t.w., a series of issues have been generated based on your blog.)
> 
> I understand the motivations you have, so let us explore it further...
> 
> What I think can be done, both from the specification point of view and, I believe, from the processing point of view is something like:
> 
> - If a number of DOM nodes share the same parent, share the same predicate URI (whether it is in a @property or a @rel) and they all have the @member then they are supposed to be in the same list referred to by the (shared) predicate.
> 
> I think this can be implemented and described in terms of DOM transformation: a new, common container node is inserted into the DOM, reparenting the nodes that are at hand, and then follow more or less the same approach as described in 
> 
> http://www.w3.org/2010/02/rdfa/wiki/Lists
> 
> And this is in line with your examples below.
> 
> There is a little bit of a caveat if an @itemref is involved (and RDFa goes along the lines of implementing that); indeed, I am not sure about a structure of the form
> 
> <bla property="foo:bar" member>Blah</bla>
> <bla property="foo:bar" itemref="toto"/>
> ...
> ...
> <bla id="toto" member>blah again</bla>
> 
> (Though I may misunderstand the behaviour of this itemref.) I would be happy to say that the whole list processing ignores this case, though.
> 
> The issue may be (_may_ be) that this way of defining lists is a bit more restricted. I am not sure how I would properly specify the following case:
> 
> ...
> <span> <span property="foo:bar" member>blah</span> </span>
> <span property="foo:bar" member>blah 2</span>
> <span><span><span><span property="foo:bar" member>deep blah</span></span></span></span>
> ...
> 
> My 'wrapper' approach takes care of this, of course, because the wrapper itself provides with the right starting point for the tree walk. It would probably be possible to specify and implement this case, too, but I expect it would be fairly complicated and arcane...
> 
> That being said, this may be a pathological case. I may go along the philosophy saying that we have a shorthand for the simple case (ie, when all nodes are on the same level in the tree) and if somebody has a more complex structure then, well, he/she is on his/her own...
> 
> Thoughts?
> 
> Thanks
> 
> Ivan
> 
> 
> 
> On Aug 26, 2011, at 07:51 , Jeni Tennison wrote:
> 
>> Ivan, Niklas, others,
>> 
>> On 24 Aug 2011, at 15:57, Ivan Herman wrote:
>>> I tried to modify my original approach based on the discussion we had:
>>> 
>>> http://www.w3.org/2010/02/rdfa/wiki/Lists
>> 
>> 
>> As you know, the issue about lists arose from trying to identify what changes might be made that would make it easier for people to combine or switch between microdata and RDFa. If you are going to introduce syntax sugar for rdf:List (which I think you should) then I'd favour something that was easy to map to the microdata over something that wasn't.
>> 
>> The example on the wiki page is:
>> 
>> <li about="http://www.worldcatlibraries.org/isbn/9780262912423" 
>>    typeof="bibo:Book">
>>  <span rel="dc:creator" collection>
>>    <span member>Grigoris Antoniou</span> and
>>    <span member>Frank van Harmelen</span>
>>  </span>
>> </li>
>> 
>> In microdata this would be:
>> 
>> <li itemid="http://www.worldcatlibraries.org/isbn/9780262912423" 
>>    itemtype="../Book">
>>  <span>
>>    <span itemprop=".../creator">Grigoris Antoniou</span> and
>>    <span itemprop=".../creator">Frank van Harmelen</span>
>>  </span>
>> </li>
>> 
>> Going the other way, a microdata example is:
>> 
>> <section itemscope itemtype="http://example.org/animals#cat">
>> <h1 itemprop="name http://example.com/fn">Hedral</h1>
>> <p itemprop="desc">Hedral is a male american domestic
>> shorthair, with a fluffy <span
>> itemprop="http://example.com/color">black</span> fur with <span
>> itemprop="http://example.com/color">white</span> paws and belly.</p>
>> <img itemprop="img" src="hedral.jpeg" alt="" title="Hedral, age 18 months">
>> </section>
>> 
>> Assuming the http://example.com/color property needed to have a list, this would turn into:
>> 
>> <section vocab="http://example.org/animals#" typeof="cat">
>> <h1 property="name http://example.com/fn">Hedral</h1>
>> <p property="desc">Hedral is a male american domestic
>> shorthair, with a fluffy <span rel="http://example.com/color" collection><span
>> member>black</span> fur with <span
>> member>white</span></span> paws and belly.</p>
>> <span rel="img"><img src="hedral.jpeg" alt="" title="Hedral, age 18 months">
>> </span>
>> </section>
>> 
>> So the RDFa proposal requires a wrapper element around the items of the list and moves the relationship onto the wrapper element, whereas the microdata one just aggregates the items based on the property.
>> 
>> While I can see the logic of the wrapper element, it does constrain the structure of the HTML. It prevents people from mixing other properties amongst the members of the list (though I struggle to come up with a persuasive example where you'd want to do that; perhaps someone else can think of one).
>> 
>> I guess an alternative that alleviates this would be:
>> 
>> <li about="http://www.worldcatlibraries.org/isbn/9780262912423" 
>>    typeof="bibo:Book">
>>  <span property="dc:creator" member>Grigoris Antoniou</span> and
>>  <span property="dc:creator" member>Frank van Harmelen</span>
>> </li>
>> 
>> This also has the advantage of making it easier to adapt existing RDFa to create lists rather than multiple triples with the same property: you just add the 'member' attribute as required. If a property element didn't have the member attribute:
>> 
>> <li about="http://www.worldcatlibraries.org/isbn/9780262912423" 
>>    typeof="bibo:Book">
>>  <span property="dc:creator" member>Grigoris Antoniou</span> and
>>  <span property="dc:creator">Frank van Harmelen</span>
>> </li>
>> 
>> then I'd suggest it wouldn't be part of the list for that property:
>> 
>> <http://www.worldcatlibraries.org/isbn/9780262912423>
>>   a bibo:Book ;
>>   dc:creator ("Grigoris Antoniou") ;
>>   dc:creator "Frank van Harmelen" ;
>>   .
>> 
>> I suggest this approach as being easy to use from an author's perspective (particularly an author who isn't used to thinking about lists as a type of resource). I'm not sure how it could be described in processing terms. Perhaps collect a map of property->list for those elements with a 'member' attribute, and when you finish processing the element turn any such maps into triples with the relevant rdf:List.
>> 
>> In short, I think that approaches to expressing lists that use a wrapper element for the list itself are going to be constraining for people to use, particularly when mixed with microdata.
>> 
>> Cheers,
>> 
>> Jeni
>> -- 
>> Jeni Tennison
>> http://www.jenitennison.com
>> 
> 
> 
> ----
> 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
> 
> 
> 
> 
> 
> 


----
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 Friday, 26 August 2011 13:49:54 UTC