Re: [whatwg] Microdata DOM API issues
On Sat, 14 Nov 2009 00:34:12 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: On Fri, Nov 13, 2009 at 5:14 PM, Philip Jägenstedt phil...@opera.com wrote: The itemref mechanism allows creating arbitrary graphs of items, rather than the tree of items that is the intended microdata model (right?). Even though my default reaction to graphs is oh cool, for microdata when the domain model is a graph you should probably just represent it with a level of indirection (RDF). Options: 1. patch the algorithms which can go into recursion 2. patch http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#associating-names-with-items to first check if an itemref'd property creates a loop before adding it to candidates 3. ? I think I prefer 2. Looping in data-graphs is often useful, so I'm not sure I want to throw it out generally. Your statement in the first paragraph I'm quoting, though, says that you'd rather leave loops to be defined in the vocabulary itself? So loops would be done by, frex, itemprop'ing a link to the other element rather than itemref'ing the other element directly? Yes, that's basically what I'm saying. One option is to simply use microdata such that the RDF you extract is the graph you want (it will probably look quite ugly though). Another is always referencing subitems by a mechanism other than refid. For example, in the MusicBrainz XML webservice when an artist contains a release which itself references artists (e.g. as the producer), a stub item is used with only artist name and id, rather than including all information recursively. In microdata I would do: section itemscope itemtype=http://musicbrainz.org/artist/; itemid=http://musicbrainz.org/artist/4d5447d7-c61c-4120-ba1b-d7f471d385b9; h1 itemprop=nameJohn Lennon/h1 section h1Releases/h1 section itemprop=release itemscope itemtype=http://musicbrainz.org/release/; itemid=http://musicbrainz.org/release/f237e6a0-4b0e-4722-8172-66f4930198bc; h1Imagine/h1 Producer: span itemprop=producer itemscope itemtype=http://musicbrainz.org/artist/; itemid=http://musicbrainz.org/artist/e7b587f7-e678-47c1-81dd-e7bb7855b0f9; span itemprop=namePhil Spector/span/span /section /section /section Even if John Lennon were the producer here, you don't get any looping in the microdata itself. If you want to know everything about the producer, you should just follow the itemid... I haven't looked that much at the RDF extraction algorithm yet, but I think this example might even create the proper graph with loops if the producer were John Lennon. That would probably be fine, and is compatible with a tree-based data model like JSON. Vocabs should know when loops are permissible/desirable for themselves. I agree, I don't see that we have a problem here. -- Philip Jägenstedt Opera Software
Re: [whatwg] Microdata DOM API issues
On Thu, 12 Nov 2009 03:23:54 +0100, Philip Jägenstedt phil...@opera.com wrote: Why are the algorithms for extracting RDF gone? All that's left is the book example with the equivalent Turtle, but it would be nice if it were actually defined how to extract RDF. The same for the JSON stuff, was that no good? D'oh! I've been reading the multipage version and missed that it's on another page: http://www.whatwg.org/specs/web-apps/current-work/multipage/converting-html-to-other-formats.html I'll have to try implementing that and see if there are any more issues. -- Philip Jägenstedt Opera Software
Re: [whatwg] Microdata DOM API issues
On Fri, 13 Nov 2009 19:27:39 +0100, Philip Jägenstedt phil...@opera.com wrote: On Thu, 12 Nov 2009 03:23:54 +0100, Philip Jägenstedt phil...@opera.com wrote: Why are the algorithms for extracting RDF gone? All that's left is the book example with the equivalent Turtle, but it would be nice if it were actually defined how to extract RDF. The same for the JSON stuff, was that no good? D'oh! I've been reading the multipage version and missed that it's on another page: http://www.whatwg.org/specs/web-apps/current-work/multipage/converting-html-to-other-formats.html I'll have to try implementing that and see if there are any more issues. http://www.whatwg.org/specs/web-apps/current-work/multipage/converting-html-to-other-formats.html#json This was easy to implement, but the algorithm isn't guaranteed to terminate. div itemscope div itemprop=foo itemscope itemref=oops id=oops/div /div This simple input causes the algorithm to recurse as the item references itself. I went back to the vCard algorithm and found that it too will fail to terminate with this input: span itemscope itemtype=http://microformats.org/profile/hcard; span itemprop=agent itemscope id=oops itemref=oops itemtype=http://microformats.org/profile/hcard; /span vEvent is safe as the algorithm never recurses, but the RDF conversion algorithm would hit the same problem. It's certainly possible to create loops which are less easy to spot: div itemscope div itemprop=prop1 itemscope itemref=id2 id=id1/div div itemprop=prop2 itemscope itemref=id3 id=id2/div ... div itemprop=propn itemscope itemref=id1 id=idn/div /div Or this: div itemscope div itemprop=foo itemscope id=a div itemprop=bar itemscope itemref=a/div /div /div The itemref mechanism allows creating arbitrary graphs of items, rather than the tree of items that is the intended microdata model (right?). Even though my default reaction to graphs is oh cool, for microdata when the domain model is a graph you should probably just represent it with a level of indirection (RDF). Options: 1. patch the algorithms which can go into recursion 2. patch http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#associating-names-with-items to first check if an itemref'd property creates a loop before adding it to candidates 3. ? I think I prefer 2. -- Philip Jägenstedt
Re: [whatwg] Microdata DOM API issues
On Fri, Nov 13, 2009 at 5:14 PM, Philip Jägenstedt phil...@opera.com wrote: The itemref mechanism allows creating arbitrary graphs of items, rather than the tree of items that is the intended microdata model (right?). Even though my default reaction to graphs is oh cool, for microdata when the domain model is a graph you should probably just represent it with a level of indirection (RDF). Options: 1. patch the algorithms which can go into recursion 2. patch http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#associating-names-with-items to first check if an itemref'd property creates a loop before adding it to candidates 3. ? I think I prefer 2. Looping in data-graphs is often useful, so I'm not sure I want to throw it out generally. Your statement in the first paragraph I'm quoting, though, says that you'd rather leave loops to be defined in the vocabulary itself? So loops would be done by, frex, itemprop'ing a link to the other element rather than itemref'ing the other element directly? That would probably be fine, and is compatible with a tree-based data model like JSON. Vocabs should know when loops are permissible/desirable for themselves. ~TJ
