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

On Sep 1, 2011, at 24:40 , Gregg Kellogg wrote:
[snip]

>> Yes, I know this is a problem. The point is: at this moment it is not clear in my mind how I would precisely specify the case when the elements are not on the same level. I still have to think about that case, ie, if it could properly work. I am a little bit afraid it may become a bit too convoluted, but maybe not (I will have a long train ride today back to Amsterdam, it will give me time to think…)
> 
> I think this may be a problem of relying on the DOM for performing identifying collection elements. For the general case, we could say that any element having both @property/@rel and @member with a common subject is added to a collection for that property. This allows the use of that property anywhere within the scope of that common subject.
> 

Yes. The problem is how to implement it properly. And, if we do not rely on the DOM approach, then we would have to modify the processing steps in the core and those are already fairly complicated... That is why I tried to keep away from those.


> This does mean that we don't have a way to encode property with more than one list:
> 
> :s :p (:o1 :o2), (:o3 :04)
> 
> But we could also support the use of @collection to specifically create a list scope. For example:
> 
> <li about="http://www.worldcatlibraries.org/isbn/9780262912423"   typeof="bibo:Book">
>  <span collection>
>    <span property="dc:creator" member>Grigoris Antoniou</span> and
>    <strong><span property="dc:creator" member>Frank van Harmelen</span></strong>
>  </span>
> </li>
> 

That was my original proposal 

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

Jeni's approach was to try to get rid of the extra layer with collection that would be necessary for that.


> Would identify that members of dc:creator within the scope of the span including @collection are added to a list defined by that span.
> 
> Secondly, we don't seem to have a way to have a list containing lists. This could be supported by having both @collection and @member on the same element, which would change the algorithm to continue processing the child elements to create a list which becomes a member of the parent list. For example:
> 
> <li about="http://www.worldcatlibraries.org/isbn/9780262912423"   typeof="bibo:Book">
>  <span property="dc:creator" member collection>
>    <span property="dc:creator" member>Grigoris Antoniou</span> and
>    <strong><span property="dc:creator" member>Frank van Harmelen</span></strong>
>  </span>
> </li>
> 
> could then create:
> 
> <http://www.worldcatlibraries.org/isbn/9780262912423> dc:creator (("Grigoris Antoniou", "Frank van Harmelen")).
> 

I think the algorithm in 

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

does that (well, that was my intention...)


Ivan


> I think this would allow us to represent any type of collection that could be represented in Turtle, and would allow a simple representation for simple lists.
> 
> Gregg
> 
>> The issue is clearer if I have this in reverse order 
>> 
>> <strong><span property="dc:creator" member>Frank van Harmelen</span></strong>
>> <span property="dc:creator" member>Grigoris Antoniou</span>
>> 
>> If the processor sees first Frank's item, it has to go up the DOM hierarchy to look for the corresponding item of Grigoris; such up-and-down search may be a bit painful. In the 'triggering' model the processor knows where to start and goes down only, in this case it is more complicated. I mainly expect issues with processors that do not necessarily have the full DOM tree in their possession but do some sort of a streaming thing.
>> 
>> B.t.w., your example above would work with
>> 
>>> <span property="dc:creator" member><strong>Frank van Harmelen</strong></span>
>> 
>> 
>> of course. Or even putting everything on the <strong>. So the question is whether this is really such a huge restriction.
>> 
>>> 
>>> I'm also not sure how your DOM-manipulation approach works. Just to make sure we're on the same wavelength, I would similarly expect:
>>> 
>>> <li about="http://www.worldcatlibraries.org/isbn/9780262912423" 
>>> typeof="bibo:Book">
>>> <span property="dc:creator" member>Grigoris Antoniou</span> from
>>> <span property="ex:org">Somewhere</span>
>>> and
>>> <strong><span property="dc:creator" member>Frank van Harmelen</span></strong>
>>> </li>
>>> 
>>> to create:
>>> 
>>> <http://www.worldcatlibraries.org/isbn/9780262912423>
>>>  a bibo:Book ;
>>>  dc:creator ("Grigoris Antoniou", "Frank van Harmelen") ;
>>>  ex:org "Somewhere" ;
>>>  .
>>> 
>>> rather than:
>>> 
>>> <http://www.worldcatlibraries.org/isbn/9780262912423>
>>>  a bibo:Book ;
>>>  dc:creator [
>>>    a rdf:List ;
>>>    rdf:first "Grigoris Antoniou" ;
>>>    rdf:rest [ 
>>>      a rdf:List ;
>>>      rdf:first "Frank van Harmelen" ;
>>>      rdf:rest rdf:nil ;
>>>    ] ;
>>>    ex:org "Somewhere" ;
>>>  ]
>>>  .
>> 
>> 
>> Yes, it works as you expect. The DOM translation mechanism (a) ignores the items without 'member' and also regroups members with the same predicates.
>> 
>> To be precise, your example (without the spams for the moment)
>> 
>> <li about="http://www.worldcatlibraries.org/isbn/9780262912423" 
>> typeof="bibo:Book">
>> <span property="dc:creator" member>Grigoris Antoniou</span> from
>> <span property="ex:org">Somewhere</span>
>> and
>> <span property="dc:creator" member>Frank van Harmelen</span>
>> </li>
>> 
>> would become
>> 
>> <li about="http://www.worldcatlibraries.org/isbn/9780262912423" 
>> typeof="bibo:Book">
>> <link_element rel="dc:creator" resource="_:1"/>
>> 
>> <span about="_:1" property="rdf:first">Grigoris Antoniou</span>
>> <link_element about="_:1" rel="rdf:rest" resource="_:2"/> 
>> 
>> from
>> <span property="ex:org">Somewhere</span>
>> and
>> 
>> <span about="_:2" property="rdf:first">Frank van Harmelen</span>
>> <link_element about="_:2" rel="rdf:rest" resource="rdf:nil"/> 
>> </li>
>> 
>> 
>>> 
>>>> 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.
>>> 
>>> In microdata, you're only allowed to put the itemref attribute on an element with itemscope attribute. For something equivalent in RDFa, I'd suggest limiting it to elements that create new subjects. It would be easiest if this could be expressed in terms of the presence of an attribute, eg just those with 'about' or 'typeof' attributes. So the above wouldn't be allowed.
>>> 
>> 
>> Aha! Ok, that takes care of it indeed.
>> 
>> Thanks Jeni!
>> 
>> Cheers
>> 
>> I.
>> 
>> 
>> (Tracker, this is also for ISSUE-106)
>> 
>> 
>> 
>>> 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 Thursday, 1 September 2011 11:31:20 UTC