Re: Weighing the ideas around itemref

On Sun, Dec 9, 2012 at 8:09 PM, Niklas Lindström <lindstream@gmail.com>wrote:

> I've been weighing the inputs and ideas that have been put forward
> regarding ISSUE-144 (an @itemref-like feature) [1]. Let's discuss the
> requirements here. Whatever we do, we must not rush things.
>
> I still believe we need more knowledge about the actual needs. What
> publishers need to do to capture their relevant content, and what
> consumers need of that and how to use it. We need solid examples,
> otherwise the claim that this is much required in the wild is moot.
>

Talking about collecting more examples, here is one page listing several
events [1] which share some properties like venue and artists. (made an
archive at [2]).

Steph.

[8] http://todossantosmusicfestival.com/lineup
[9] http://files.openspring.net/2012/lineup.html


>
> I have observed two aspects of @itemref which we do *not* need to
> reproduce:
>
> 1) Based on the microdata spec, and some online articles (e.g. [2],
> [3]), @itemref is sometimes used to capture data about a resource
> which is not nested within the element/@itemscope in question. As has
> been said many times, this has always been a basic feature of RDFa,
> since it supports specifying the subject (using @resource (and in
> full, @about)) in the portion where the data exists.
>
> (I have used this many times, e.g. when adding RDFa to our company
> intranet. Using @itemref there instead would have made the solution
> brittle and hard to grasp, since the subject for a piece of content
> would only be discernible by noticing that the local @id was actually
> used in an @itemref elsewhere in the template source, often spread
> across files.)
>
> 2) In this stackoverflow thread [4] the practise of linking to
> resources is oddly done by using @itemref (instead of using references
> with an @itemid, which is mainly like @resource). It also seems that
> GoodRelations recommends this [5]. IIUC, the consequence, according to
> the microdata algorithm, is basically a copying by value, resulting in
> two different items (bnodes), instead of linking to the same resource.
> This copying is not apparent of course; in the thread this is thought
> of as linking data.
>
> (And I don't blame them; the name @iremref certainly implies that it
> is used for making item references, not element references for a
> parser to jump to.. From what I've gathered, it basically instructs a
> parser that "this item is also described by the content blocks at
> these IDs". Basically an @itemdescriptionref.. Please correct me if
> I'm missing a point here.)
>
> So whatever we're after here, it doesn't need to be the exact
> equivalent of @itemref (in fact, given the above, that would be a
> costly choice in terms of complexity). We need to define the core of
> what is sought after.
>
> AFAIK, we have so far received two instances where an @itemref feature
> is said to be needed:
>
> 1) Martin Hepp initially reported that @itemref is necessary in real
> world usage. Unfortunately, we haven't gotten any real examples
> supporting this claim. From what I have gathered, the case described
> is readily solved by using a ProductModel. If is is not, it is yet
> unclear whether adding link and meta elements would suffice or not.
> How many properties are to be copied into each product? (And are there
> no dedicated product pages with more details, given the apparent need
> to discover each product in search engines?)
>
> What other cases like this are there? Do sub-events need to copy
> certain properties from their parent events? All properties or just a
> handful? (Certainly the "subEvent" relation must not be copied, so
> using @itemref to copy the parent data seems off.) This is the source
> of our prototype idea, which I've been entertaining for a while. It is
> alluring, and quite easy to implement. But that doesn't equate with
> utility. I still don't know if the needs presented really demand it. I
> think we need more experience and input here.
>
> 2) The other case is from Jason Ronallo. This example [6] uses
> @itemref to reuse a name, an image and a set of keywords between an
> ItemPage, LandmarksOrHistoricalBuildings and CreativeWork (please see
> the source to understand the details). In a way it is similar to the
> Product case, with the potential difference (depending on how
> important the ProductModel is as a concept in that example) that the
> copied data here is also used within an itemscope to describe an
> entity. And especially that this is mostly about picking out a few
> pieces to avoid repetition in hidden @content. I do sympathize with
> the desire to avoid duplication, but in general I still think the
> repetition in meta and link elements would be fairly negligible. (And
> that such direct use makes the effect much clearer, and reduces
> complexity.)
>
> I've put a version of that example as RDFa using our experimental
> prototypes at [7]. It certainly works, but I wonder if it's necessary.
>
> Perhaps it would be enough if there was a mechanism to reuse a literal
> value from another place in the document? That would remove the need
> of sometimes copying the same textual value into several descriptions
> within a page (often hidden in @content of meta elements). This could
> be done by adding a new @contentref attribute:
>
>     <div resource="#page" typeof="ItemPage">
>       <h1 property="name" id="page_name">A Very Long Name Which Would
> Be Tedious To Repeat</h1>
>       <div property="about" resource="#creativework" typeof="CreativeWork">
>         <meta property="name" contentref="page_name"/>
>       </div>
>     </div>
>
> This would only copy the literal value. The @property (and any
> @datatype) will be on the "start" element which uses the @contentid.
> So in a way it would be like @datetime or @value in HTML5, just
> indirected via an @id lookup. Adding just this would still require
> repetition of links and meta elements though (e.g. for multiple
> keywords). It would just remove the need for repeating literal
> content. The question is still open whether that would suffice. I'm
> suggesting this mostly to promote a balance of requirements.
>
> The remaining, *very important* question, is whether search engines
> penalize usage of meta and link elements? This has come up time and
> again as a point of uncertainty for authors. I hope Schema.org
> representatives can answer this, since it is a generally useful
> pattern at times. I would expect it to be perfectly fine to add some
> precision, as long as neither content nor links deviate in subject
> matter. (There are many other ways to add hidden content for
> subversive SEO purposes.)
>
> Best regards,
> Niklas
>
> [1]: http://www.w3.org/2010/02/rdfa/track/issues/144
> [2]: http://html5doctor.com/microdata/
> [3]:
> http://net.tutsplus.com/tutorials/html-css-techniques/html5-microdata-welcome-to-the-machine/
> [4]:
> http://stackoverflow.com/questions/8726413/schema-org-itemref-linking-multiple-sportevents-to-a-single-place
> [5]: http://wiki.goodrelations-vocabulary.org/Cookbook/Video_content
> [6]:
> http://d.lib.ncsu.edu/collections/catalog/mc00096-001-ff0155-000-001_0001
> [7]: https://gist.github.com/4243921
>
>


-- 
Steph.