- From: Ivan Herman <ivan@w3.org>
- Date: Fri, 26 Aug 2011 09:06:55 +0200
- To: Jeni Tennison <jeni@jenitennison.com>
- Cc: Lin Clark <lin.w.clark@gmail.com>, public-rdfa-wg@w3.org
(tracker, this is for ISSUE-105) On Aug 26, 2011, at 08:14 , Jeni Tennison wrote: > Ivan, > > On 25 Aug 2011, at 16:22, Ivan Herman wrote: >> As you may have seen on Jeni's G+ discussion, I have given some thought to this in terms of RDFa. Everything can be done of course but the issue we would be facing (and I do not know how microdata solves that, actually) is what 'state' would the referred entry be. What happens to language setting, to @prefix settings, types/vocabularies, etc. What I am afraid of is that the 'referred' part would generate different RDF triples depending on where it is included into, and that sounds problematic to me... > > > FWIW, that is effectively how the itemref mechanism works in microdata: if the referenced element includes short-name properties then those will be interpreted based on the itemtype of the referencing element. So the same content could be referenced from two different places and have different semantics each time. Hem. O.k. I find it a bit weird, I must admit but, well... > > In microdata's case, that could be useful, because you might have several types that actually share properties with the *same* semantics (through inheritance; see schema.org for example). I suspect that the risk of people unknowingly using it to create weird data is low compared to the benefit that the flexibility provides. > > Scoping in RDFa is rather different of course. If you were supporting an equivalent to itemref, it might be better to (conceptually) have a pre-processing step that uses the DOM tree to resolve terms and CURIEs, languages and so on, and then a parsing step that generates triples from the results. Or, equivalently, you could describe the resolution of terms/CURIEs/languages etc in terms of looking up the DOM tree rather than as information that you pass around in the evaluation context. (Either of these approaches would simplify the processing algorithm in the specification in any case.) > If we accepted the microdata approach, ie, that the refereed portion is some sort of a macro then your original idea (on G+) is also perfectly viable. The current processing steps/algorithm is essentially going through the tree; itemref would mean, at each step, not to consider the real children only, but a virtual one through the resolution of the itemref id. Otherwise things would behave exactly the same. So yes, algorithmically that is easy to define and implement, but I would really have to be pushed hard:-) to say that it is all right. I am very curious to see if Lin's use case really needs this or whether the fact that RDFa has explicit control over URI-s and @about and @resource does not solve the same issue... Cheers, Ivan > 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
Received on Friday, 26 August 2011 07:04:20 UTC