- From: Ivan Herman <ivan@w3.org>
- Date: Sat, 8 Dec 2012 09:28:51 -0500
- To: Gregg Kellogg <gregg@greggkellogg.net>
- Cc: Dan Brickley <danbri@danbri.org>, W3C RDFa WG <public-rdfa-wg@w3.org>
On Dec 7, 2012, at 18:59 , Gregg Kellogg wrote:
> On Dec 7, 2012, at 3:46 PM, Ivan Herman <ivan@w3.org> wrote:
>
>>
>> On 7 Dec 2012, at 17:12, Gregg Kellogg <gregg@greggkellogg.net> wrote:
>>
>>> I added experimental support to my parser (will deploy to distiller later) as part of vocabulary expansion.
>>
>> Kudos! But does it mean that I have to switch vocab expansion on to get this, or does this happen automatically?
>
> Turn on expansion, mostly because this is just experimental. It could be made the default action easily enough, but right now it's just coupled with the expansion rules.
Right. The question is really how we would define it for processors. At this point we can only _require_ it for HTML5 processors of course.
>
>>> 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 .
>>> }
>>>
>>
>> I am not sure understand. Shouldn't be ?PR rdf:type rdfa:Prototype ? And I am not sure it it is good to remove that, because the prototype triples are also present in the output graph, and it is good to keep this typing as an 'annotation'...
>
> No, without this rule, then ?x also gets type rdfa:Prototype, which doesn't make sense.
Ah! Right. I think the equivalent, but, for communication purposes, clearer is to write down the rules as:
INSERT DATA {
?x ?p ?y .
}
DELETE DATA {
?x rdfa:ref ?PR .
?PR ?p ?y .
?PR rdf:type rdfa:Prototype .
}
WHERE {
?x rdfa:ref ?PR .
?PR ?p ?y.
FILTER ( !(?p = rdf:type && ?y = rdfa:Prototype) )
?PR a rdfa:Prototype .
}
Actually, this may not be fine. I am not aware of the details of SPARQL UPDATE, but, operationally, doing it this way would remove the rdfa:Prototype too early, so to say, ie, it would create problems if the same prototype is used twice. Ie, I would probably define this as two rules, to be executed one after the other (note that I made a syntactic error SPARQL -wise, in my previous format):
INSERT {
?x ?p ?y .
}
DELETE {
?x rdfa:ref ?PR .
?PR ?p ?y .
?PR rdf:type rdfa:Prototype .
}
WHERE {
?x rdfa:ref ?PR .
?PR ?p ?y.
FILTER ( !(?p = rdf:type && ?y = rdfa:Prototype) )
?PR a rdfa:Prototype .
}
;
DELETE WHERE {
?x rdfa:type rdfa:Prototype .
}
I am actually not sure that your simple modification of the DELETE covers this case, I did not really checked...
> The ?PR rdf:type rdfa:Prototype isn't necessary, as it's covered by ?PR ?p ?y. Without this rule, the result of the first example would look like:
>
> @prefix schema: <http://schema.org/> .
> [a schema:Person, rdfa:Prototype; schema:name "Amanda"] .
>
>>> Here are some example tests, based on those used by the Microdata RDF note:
>>
>> In all those examples, the prototype triples should also be present, shouldn't they?
>
> No, the DELETE DATA { ?PR ?p ?y } removes them.
Ah, silly me. That is true. _Except_ the pathological case when one defines a prototype without really using it. In which case, hm, my second rule would probably be harmful, because it is better to keep the whole structure in its original form; ie, it should be applied only in case there was any change on the graph.
Ivan
>
> Gregg
>
>> Ivan
>>
>>
>>>
>>> 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
Received on Saturday, 8 December 2012 14:29:18 UTC