- From: Ivan Herman <ivan@w3.org>
- Date: Fri, 26 Aug 2011 13:21:17 +0200
- To: Shane McCarron <shane@aptest.com>
- Cc: public-rdfa-wg@w3.org
True. But, as far as I know, HTML5 allows
<bla member>blah</bla>
and the generated DOM tree node will have a member="" attribute.
This means that the XML version would simply refer to the existence of the member attribute without caring about its content.
Ivan
On Aug 26, 2011, at 13:13 , Shane McCarron wrote:
> FYI - XML does not permit attributes that do not have values. So we cannot have @member on its own. We could have @member="member" or @member="IDREF" or @member="".
>
> Sorry to thread crap.
>
> On 8/26/2011 5:15 AM, 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
>>
>>
>>
>>
>>
>>
>
> --
> Shane McCarron
> Managing Director, Applied Testing and Technology, Inc.
> +1 763 786 8160 x120
>
>
----
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 11:18:39 UTC