- From: Ivan Herman <ivan@w3.org>
- Date: Mon, 31 Dec 2012 06:31:46 +0100
- To: Gregg Kellogg <gregg@greggkellogg.net>
- Cc: Dan Brickley <danbri@danbri.org>, W3C RDFa WG <public-rdfa-wg@w3.org>
- Message-Id: <3B7B7440-9D44-41B2-BE9C-6F9B05DAEB64@w3.org>
Gregg,
this looks perfect to me. And forget about the entailment lemma, I do not think it is important.
Ivan
On Dec 30, 2012, at 21:05 , Gregg Kellogg <gregg@greggkellogg.net> wrote:
> I can re-state my antecedent/consequent rules in terms of RDFS Entailment descriptions. I don't think I want to go as far as the formal entailment lemmas from RDFS (but if someone else is up to it, a semantics sub-section would be great), but we can certainly use the same terminology. This isn't really entailment, from my understanding, as the resulting graph is not a strict-superset of the original graph, as the rdfa:Prototype triples are removed. But we can reference (informatively) section 7 of RDFS "Entailment rules" along with section 10 from RDFa Core 1.1 "RDFa Vocabulary Expansion" and indicate that these rules can be implemented as a mandatory extension to RDFa Vocabulary Expansion, not under the control of a processor option.
>
> I would basically define the following rules:
>
> Rule rdfa-ref:
>
> If, after processing the document, the resulting graph contains the following triples:
>
> xxx rdfa:ref rrr
> rrr rdf:type rdfa:Prototype
> rrr ppp ooo
>
> then add the resulting triples
>
> xxx ppp ooo
>
> Rule rdfa-rdf-remove:
>
> After fully expanding triples from rule rdfa-ref, if the resulting graph contains the following triples:
>
> xxx rdfa:ref rrr
> rrr rdf:type rdfa:Prototype
> rrr ppp yyy
>
> then remove the resulting triples from the output graph:
>
> xxx rdfa:ref rrr
> xxx rdf:type rdfa:Prototype
> rrr ppp ooo
>
> I would then include an example showing multi-level reference folding with a test such as the following:
>
> <div>
> <div typeof="schema:Person">
> <link property="rdfa:ref" resource="_:a"/>
> <link property="rdfa:ref" resource="_:b"/>
> </div>
> <p resource="_:a" typeof="rdfa:Prototype">Name: <span property="schema:name">Amanda</span></p>
> <div resource="_:b" typeof="rdfa:Prototype">
> <div property="schema:band" typeof=" schema:MusicGroup">
> <link property="rdfa:ref" resource="_:c"/>
> </div>
> </div>
> <div resource="_:c" typeof="rdfa:Prototype">
> <p>Band: <span property="schema:name">Jazz Band</span></p>
> <p>Size: <span property="schema:size">12</span> players</p>
> </div>
> </div>
>
> should produce
>
> @prefix schema: <http://schema.org/> .
> [ a schema:Person;
> schema:name "Amanda" ;
> schema:band [
> a schema:MusicGroup;
> schema:name "Jazz Band";
> schema:size "12"
> ]
> ] .
>
> Unless I hear otherwise, I'll update the rdfa-in-html document and test-suite accordingly.
>
> Gregg Kellogg
> gregg@greggkellogg.net
>
> On Dec 30, 2012, at 12:27 AM, Ivan Herman <ivan@w3.org> wrote:
>
>>
>> On Dec 29, 2012, at 22:47 , Gregg Kellogg <gregg@greggkellogg.net> wrote:
>>
>>> As I noted elsewhere, I provisionally added this to the HTML+RDFa spec [1]. I was going to add some test cases to the test suite for it, but it struck me that we had not discussed the use case of rdf:Prototype elements themselves using rdf:ref. I illustrated this in an example I sent out earlier:
>>>
>>> <div>
>>> <div typeof="schema:Person">
>>> <link property="rdfa:ref" resource="_:a"/>
>>> <link property="rdfa:ref" resource="_:b"/>
>>> </div>
>>> <p resource="_:a" typeof="rdfa:Prototype">Name: <span property="schema:name">Amanda</span></p>
>>> <div resource="_:b" typeof="rdfa:Prototype">
>>> <div property="schema:band" typeof=" schema:MusicGroup">
>>> <link property="rdfa:ref" resource="_:c"/>
>>> </div>
>>> </div>
>>> <div resource="_:c" typeof="rdfa:Prototype">
>>> <p>Band: <span property="schema:name">Jazz Band</span></p>
>>> <p>Size: <span property="schema:size">12</span> players</p>
>>> </div>
>>> </div>
>>>
>>> In this case, _:b is an rdfa:Prototype which in-turn references _:c. Using the SPARQL implementation Ivan sent out, and I included in the spec, this would, in fact, not work, as the INSERT would need to be repeated until no new triples were added before there could be a DELETE. (My implementation, piggybacking on vocabulary expansion and using antecedent/consequent patterns, could handle this). We have a couple of ways to go:
>>>
>>> 1) explicitly allow this, and require that the equivalent of a SPARQL INSERT be performed until no additional triples are added to the graph,
>>> 2) explicitly disallow this, and generate an error if it is so detected, and not generate triples from deeper references, or
>>> 3) explicitly disallow this, generate a warning, and describe the behavior as being undefined.
>>
>> Or use a different formalism. There is nothing that binds us to the SPARQL formalism; if we provide the rules using, e.g., the formalism in the RDF Semantics document (which makes sense because we refer to those for the inference part as well), then we can do that. We have to separate the 'remove' rules separately, but that is all right.
>>
>> It actually may be better because people might more easily translate that into real implementations.
>>
>> I would prefer to allow this. Put it another way, it would be more complicated to justify and check disallowing it, although I do not see that as a major use case.
>>
>> Thanks!
>>
>> Ivan
>>
>>>
>>> For the time being, I'll add some test cases, but not address the "chaining" reference use case.
>>>
>>> Gregg Kellogg
>>> gregg@greggkellogg.net
>>>
>>> On Dec 12, 2012, at 12:05 PM, Ivan Herman <ivan@w3.org> wrote:
>>>
>>>> For the records, I have also added this to my implementation and it passes all the tests in this mail.
>>>>
>>>> I have not updated the pyRdfa server; I want to do that only if we agree that this is the path to follow (whether we put it in as an 'at risk' feature or not). I have created a separate 'prototype' branch on my github pyrdfa3 repo (and I have not made any change on the core RDFLib repo, will do that only if we decide to go ahead with this.)
>>>>
>>>> Ivan
>>>
>>> [1] http://www.w3.org/2010/02/rdfa/sources/rdfa-in-html/Overview-src.html#rdfa-reference-folding
>>>
>>>> On Dec 7, 2012, at 17:12 , Gregg Kellogg wrote:
>>>>
>>>>> I added experimental support to my parser (will deploy to distiller later) as part of vocabulary expansion. I pretty much implement Ivan's algorithm as part of RDFa vocabulary expansion, with the following difference:
>>>>>
>>>>> I modified the DELETE clause to remove the rdfa:Prototype on the subject resource as well:
>>>>>
>>>>> DELETE DATA {
>>>>> ?x rdfa:ref ?PR .
>>>>> ?x rdf:type rdfa:Prototype .
>>>>> ?PR ?p ?y .
>>>>> }
>>>>>
>>>>> Here are some example tests, based on those used by the Microdata RDF note:
>>>>>
>>>>> To a single ID:
>>>>>
>>>>> <div>
>>>>> <div typeof="schema:Person">
>>>>> <link property="rdfa:ref" resource="_:a"/>
>>>>> </div>
>>>>> <p resource="_:a" typeof="rdfa:Prototype">Name: <span property="schema:name">Amanda</span></p>
>>>>> </div>
>>>>>
>>>>> should produce
>>>>>
>>>>> @prefix schema: <http://schema.org/> .
>>>>> [a schema:Person; schema:name "Amanda"] .
>>>>>
>>>>> Adds additional property:
>>>>>
>>>>> <div>
>>>>> <div typeof="schema:Person">
>>>>> <p>My name is <span property="schema:name">Gregg</span></p>
>>>>> <link property="rdfa:ref" resource="_:surname"/>
>>>>> </div>
>>>>> <p resource="_:surname" typeof="rdfa:Prototype">My name is <span property="schema:name">Kellogg</span></p>
>>>>> </div>
>>>>>
>>>>> should produce
>>>>>
>>>>> @prefix schema: <http://schema.org/> .
>>>>> [ a schema:Person; schema:name "Gregg", "Kellogg"] .
>>>>>
>>>>> Multiple subjects with different types:
>>>>>
>>>>> <div>
>>>>> <div typeof="schema:Person">
>>>>> <link property="rdfa:ref" resource="_:a"/>
>>>>> </div>
>>>>> <div typeof="foaf:Person">
>>>>> <link property="rdfa:ref" resource="_:a"/>
>>>>> </div>
>>>>> <p resource="_:a" typeof="rdfa:Prototype">Name: <span property="schema:name foaf:name">Amanda</span></p>
>>>>> </div>
>>>>>
>>>>> should produce
>>>>>
>>>>> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
>>>>> @prefix schema: <http://schema.org/> .
>>>>> [ a schema:Person; schema:name "Amanda"; foaf:name "Amanda"] .
>>>>> [ a foaf:Person; schema:name "Amanda"; foaf:name "Amanda"] .
>>>>>
>>>>> Multiple references:
>>>>>
>>>>> <div>
>>>>> <div typeof="schema:Person">
>>>>> <link property="rdfa:ref" resource="_:a"/>
>>>>> <link property="rdfa:ref" resource="_:b"/>
>>>>> </div>
>>>>> <p resource="_:a" typeof="rdfa:Prototype">Name: <span property="schema:name">Amanda</span></p>
>>>>> <p resource="_:b" typeof="rdfa:Prototype"><span property="schema:band">Jazz Band</span></p>
>>>>> </div>
>>>>>
>>>>> should produce
>>>>>
>>>>> @prefix schema: <http://schema.org/> .
>>>>> [ a schema:Person;
>>>>> schema:name "Amanda";
>>>>> schema:band "Jazz Band";
>>>>> ] .
>>>>>
>>>>>
>>>>> With chaining:
>>>>>
>>>>> <div>
>>>>> <div typeof="schema:Person">
>>>>> <link property="rdfa:ref" resource="_:a"/>
>>>>> <link property="rdfa:ref" resource="_:b"/>
>>>>> </div>
>>>>> <p resource="_:a" typeof="rdfa:Prototype">Name: <span property="schema:name">Amanda</span></p>
>>>>> <div resource="_:b" typeof="rdfa:Prototype">
>>>>> <div property="schema:band" typeof=" schema:MusicGroup">
>>>>> <link property="rdfa:ref" resource="_:c"/>
>>>>> </div>
>>>>> </div>
>>>>> <div resource="_:c" typeof="rdfa:Prototype">
>>>>> <p>Band: <span property="schema:name">Jazz Band</span></p>
>>>>> <p>Size: <span property="schema:size">12</span> players</p>
>>>>> </div>
>>>>> </div>
>>>>>
>>>>> should produce
>>>>>
>>>>> @prefix schema: <http://schema.org/> .
>>>>> [ a schema:Person;
>>>>> schema:name "Amanda" ;
>>>>> schema:band [
>>>>> a schema:MusicGroup;
>>>>> schema:name "Jazz Band";
>>>>> schema:size "12"
>>>>> ]
>>>>> ] .
>>>>>
>>>>> Shared resource:
>>>>>
>>>>> <div>
>>>>> <div typeof=""><link property="rdfa:ref" resource="_:a"/></div>
>>>>> <div typeof=""><link property="rdfa:ref" resource="_:a"/></div>
>>>>> <div resource="_:a" typeof="rdfa:Prototype">
>>>>> <div property="schema:refers-to" typeof="">
>>>>> <span property="schema:name">Amanda</span>
>>>>> </div>
>>>>> </div>
>>>>> </div>
>>>>>
>>>>> should produce:
>>>>>
>>>>> @prefix schema: <http://schema.org/> .
>>>>> [ schema:refers-to _:a ] .
>>>>> [ schema:refers-to _:a ] .
>>>>> _:a schema:name "Amanda"
>>>>>
>>>>>
>>>>> I'll have my updated distiller released support this later today.
>>>>>
>>>>> Gregg
>>>>>
>>>>> On Dec 7, 2012, at 11:22 AM, Ivan Herman <ivan@w3.org> wrote:
>>>>>
>>>>>>
>>>>>> On Dec 7, 2012, at 14:00 , Dan Brickley wrote:
>>>>>>
>>>>>>>
>>>>>>> On 7 Dec 2012 15:21, "Ivan Herman" <ivan@w3.org> wrote:
>>>>>>>>
>>>>>>>> Hi guys,
>>>>>>>>
>>>>>>>> I tried to reproduce what Gregg/Niklas were considering yesterday and, I believe, here are the rules that we may define and then use a post-processing step on the resulting graph that execute those:
>>>>>>>>
>>>>>>>> INSERT DATA {
>>>>>>>> ?x ?p ?y .
>>>>>>>> }
>>>>>>>> DELETE DATA {
>>>>>>>> ?x rdfa:ref ?PR .
>>>>>>>> ?PR ?p ?y .
>>>>>>>> }
>>>>>>>> WHERE {
>>>>>>>> ?x rdfa:ref ?PR .
>>>>>>>> ?PR ?p ?y.
>>>>>>>> ?PR a rdfa:Prototype .
>>>>>>>> }
>>>>>>>>
>>>>>>>> Ie, if I have somewhere:
>>>>>>>>
>>>>>>>> <div resource="#p" typeof="rdfa:Prototype">
>>>>>>>> <span property="foo">bar</span>
>>>>>>>> </div>
>>>>>>>
>>>>>>> ....ah, so you're using special terms in an rdf vocab, to avoid making extra syntax?
>>>>>>>
>>>>>>> If this <div> had nested subelements, which part would be in the Prototype?
>>>>>>
>>>>>> Everything. The whole lot:-)
>>>>>
>>>>>>>
>>>>>>>> ...
>>>>>>>> ...
>>>>>>>>
>>>>>>>> <div resource="#A">
>>>>>>>> <span property="yep">Yep Yep</span>
>>>>>>>> <span property="rdfa:ref" resource="#p"/>
>>>>>>>> </div>
>>>>>>>>
>>>>>>>> then what I would the following graph:
>>>>>>>>
>>>>>>>> <#A>
>>>>>>>> <yep> "Yep Yep" ;
>>>>>>>> <foo> "bar" .
>>>>>>>>
>>>>>>>> <#p> a rdfa:Prototype ;
>>>>>>>> <foo> "bar" .
>>>>>>>>
>>>>>>>>
>>>>>>>> Which is roughly a @itemref as we know it. I think it works and can be implemented without too much problems.
>>>>>>>
>>>>>>>
>>>>>>> Thanks for investigating this issue!
>>>>>>>
>>>>>>>> Here, though, the problems I see with this. I do not consider these as show stoppers but we have to realize those
>>>>>>>>
>>>>>>>> - As you see, the triples on the prototype itself also make it in the final graph. I am not sure it is o.k., but I also do not know how to remove them. We could define, in the SPARQL 1.1 terms, some sort of a property path based DELETE DATA clause, but implementation of that might be a bit difficult. I am not sure it is worth it.
>>>>>>>>
>>>>>>>
>>>>>>> I assume SPARQL is purely for documentational convenience / spec here, and not a real dependency?
>>>>>>
>>>>>> Yes. At the moment, that is the only syntax that can express all these rules (cannot express removal in N3:-(
>>>>>
>>>>> Pretty easy to do; I just create an additional rule to match the statements to be removed, and remove them from my output graph.
>>>>>
>>>>>>>
>>>>>>>> - The pattern I used above is of course fine. But what happens if the user does the following:
>>>>>>>>
>>>>>>>> <div property="rdf:type" resource="rdfa:Prototype>
>>>>>>>> <span property="foo">bar</span>
>>>>>>>> </div>
>>>>>>>>
>>>>>>>> the subject, ie, the ?PR in the SPARQL pattern, would be anything that was inherited, which may lead to funny situations. In other words, we do give a rope to the user to hand himself, although I agree that this is very much a corner case.
>>>>>>> I do worry about mixing vocab and syntax for such reasons.
>>>>>>>
>>>>>>>> - Would the execution of those rules be a required feature? If so, we would have to talk to the Google implementers (via DanBri) whether they would implement this at all. If not, the major use case of introducing this falls...
>>>>>>> I don't fully understand. But I'd like to work this through next week with examples...
>>>>>>
>>>>>> O.k.
>>>>>>
>>>>>> For reference, there was another approach:
>>>>>>
>>>>>> http://lists.w3.org/Archives/Public/public-rdfa-wg/2012Nov/0003.html
>>>>>>
>>>>>> which was based on the idea of a DOM manipulation *before* any type of RDFa processing, but reproducing a similar feature to @itemref. There are also issues with that one
>>>>>>
>>>>>> - does not work (well) if a streaming parser is used
>>>>>> - for any implementation that is in a browser, it should start by duplicating the DOM and work on that one; indeed, manipulating the DOM that is also used for display is not a good idea:-(
>>>>>>
>>>>>> I am not 100% which of the two approaches I prefer (if we do anything, that is). I still tend to prefer the DOM manipulation one that seems to have less caveats for me, but that is just a mild preference...
>>>>>>
>>>>>> Ivan
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> cheers,
>>>>>>>
>>>>>>> Dan
>>>>>>>
>>>>>>>> Food for thought...
>>>>>>>>
>>>>>>>> Ivan
>>>>>>>>
>>>>>>>>
>>>>>>>> ----
>>>>>>>> Ivan Herman, W3C Semantic Web Activity Lead
>>>>>>>> Home: http://www.w3.org/People/Ivan/
>>>>>>>> mobile: +31-641044153
>>>>>>>> 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
>>>>>> 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
>>>> 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
>> 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
FOAF: http://www.ivan-herman.net/foaf.rdf
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Monday, 31 December 2012 05:32:15 UTC