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

On Sep 5, 2011, at 6:06 AM, Ivan Herman wrote:

> So... I have gone through the wiki and I think this looks fine. I have not implemented yet, but marked up my code with the changes that have to be done. It indeed does not look like overly complex.
>
> Gregg, I believe there is one minor buglet: in your comment for 7.5 step 9 you say:
>
> [[[
> If the local collection mappings does not contain a collection associated with this IRI, instantiate a new collection and add to local collection mappings.
> ]]]
>
> which is correct, but I think the same comment (ie, the necessity to generate a new collection for a hitherto unused @member @rel) should be added to 7.5 step 8 =, too.

Yes, this is in my implementation, but I failed to add it to the notes. I'll update the Lists Wiki [1].

BTW, sorry, I ended up modifying the Lists entry, not JLists [2], which you had started. Feel free to reorganize as you see fit, if necessary.

Gregg

[1] http://www.w3.org/2010/02/rdfa/wiki/Lists
[2] http://www.w3.org/2010/02/rdfa/wiki/JLists

> I will come back to you guys if and when I have really implemented it...
>
> Ivan
>
>
> On Sep 4, 2011, at 23:37 , Gregg Kellogg wrote:
>
>> I updated the Wiki entry [1] with the @member-only alternative and changes to the processing rules. Note, I added additional rules for steps 9 and 11 to account for incomplete triples.
>>
>> This was required to implement the following use case:
>>
>> <div about ="">
>> <ol rel="rdf:value" member="">
>>   <li><a href="foo">Foo</a></li>
>>   <li><a href="bar">Bar</a></li>
>> </ol
>> </div>
>>
>> In spite of the added complexity to the core processing algorithm, this is the way I've implemented collection support in my processor, and I think it's useful for those interested in doing SAX-type processing, where a modification to the DOM is not possible, or for a JavaScript implementation that does not want to potentially affect the presentation.
>>
>> Gregg
>>
>> [1] http://www.w3.org/2010/02/rdfa/wiki/Lists
>>
>> On Sep 2, 2011, at 12:23 PM, Gregg Kellogg wrote:
>>
>>> So, I've implemented Jeni's suggested syntax in my parser with updated processing rules. I'll add a section to the Wiki entry that describes this in more detail. I also attempted to add support for nested lists (e.g., :a :b (("foo") ("bar") "baz"), but this proved to add too much complexity and too many corner-cases, so I don't see how we can express the full range of lists available in other languages, but it is probably enough for real-world use cases.
>>>
>>> Basically, adding @member to an element containing either @rel or @property causes the value to be added to a collection (rdf:List) associated with the current subject and predicate(s). Here are some examples:
>>>
>>> Empty List: <> rdf:value () .
>>>
>>>          <div about ="">
>>>            <p rel="rdf:value" resource="rdf:nil"/>
>>>          </div>
>>>
>>> List with mixed IRI/Literal elements: <> rdf:value ("Foo" <foo>) .
>>>
>>>          <div about ="">
>>>            <p property="rdf:value" member="">Foo</p>
>>>            <a rel="rdf:value" member="" href="foo">Foo</p>
>>>          </div>
>>>
>>> List with properties at different levels: <> rdf:value ("Foo" "Bar") .
>>>
>>>          <div about ="">
>>>            <p property="rdf:value" member="">Foo</p>
>>>            <strong><p property="rdf:value" member="">Bar</p></strong>
>>>          </div>
>>>
>>> Property with list and literal: <> rdf:value ("Foo" "Bar"), "Baz" .
>>>
>>>          <div about ="">
>>>            <p property="rdf:value" member="">Foo</p>
>>>            <strong><p property="rdf:value" member="">Bar</p></strong>
>>>            <p property="rdf:value">Baz</p>
>>>          </div>
>>>
>>> Two lists: <foo> rdf:value ("Foo"), ("Bar") .
>>>
>>>          <div>
>>>            <div about ="foo">
>>>              <p property="rdf:value" member="">Foo</p>
>>>            </div>
>>>            <div about="foo">
>>>              <p property="rdf:value" member="">Bar</p>
>>>            </div>
>>>          </div>
>>>
>>> The basic changes to the spec are the following:
>>>
>>> 5. Attributes and Syntax
>>>
>>> [[[
>>> @member
>>> an attribute (value ignored) used to indicate that the object associated with a
>>> @rel or @property attribute on the same element is to be added to the collection
>>> for that property. Causes a collection to be created if it does not already exist.
>>>
>>> ]]]
>>>
>>> 7.2 Evaluation Context
>>>
>>> [[[
>>> The _collection mappings_, a mapping from IRIs to collections.
>>> ]]]
>>>
>>> 7.5 step 1
>>> add to local values:
>>>
>>> [[[
>>> the _collection mappings_ is set to the _collection mappings_ from the _evaluation context_.
>>> ]]]
>>>
>>> 7.5 step 7, add the following
>>>
>>> [[[
>>> If the _new subject_ is set and is not the same as _parent object_, replace the _collection mappings_ taken from the _evaluation context_ with a new empty mappings.
>>> ]]]
>>>
>>> 7.5 step 8
>>>
>>> [[[
>>> If present, @rel may contain one or more IRIs, ...
>>> If the current element also has a @member attribute, the current object resource is added to a collection associated with that IRI in the local _collection mappings_, otherwise the current object resource is used to generate tripes as follows: ...
>>> ]]]
>>>
>>> 7.5 step 10
>>>
>>> [[[
>>> If the current element has a @member attribute, the current object literal is added to a collection associated with that IRI in the local _collection mappings_, otherwise the value is used to generate tripes as follows: ...
>>> ]]]
>>>
>>> 7.5 step 12
>>>
>>> [[[
>>> * the _collection_mappings is set to the value of the _local collection mappings_.
>>> ]]]
>>>
>>> 7.5 step 13 (new, required as collection processing can't complete until child elements are processed)
>>>
>>> [[[
>>> After traversing through child elements, for each IRI and collection in the _local collections mapping_, if the equivalent collection does not exist in the _evaluation context_:
>>>
>>> 1) Generate an rdf:List using elements from the collection (processing details basically the same as for Turtle or RDF/XML to be detailed later). (Note, this process does not produce empty lists, that must be done explicitly using rdf:nil).
>>> 2) Generate a triple with new subject, IRI and the BNode identifying the collection.
>>> ]]]
>>>
>>> Gregg
>>>
>>> On Sep 1, 2011, at 4:30 AM, Ivan Herman wrote:
>>>
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
> ----
> 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 Monday, 5 September 2011 16:20:06 UTC