Re: HTML+RDFa 1.1 Last Call Draft is Ready

On Jan 28, 2013, at 8:18 PM, Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 01/27/2013 10:42 AM, Niklas Lindström wrote:
>> 1. In "3.5 Property Copying": Should a rdfa:Pattern really only be 
>> removed if it has been used (i.e. linked to with rdfa:copy)? 
>> Otherwise, the final removal step should remove rdfa:copy links in
>> one step and every statement about an rdfa:Pattern in another. (Did 
>> Gregg's original text specify it like this?)
> 
> Fixed (I hope). Please double-check my work to make sure it achieves the
> issues both you and Gregg pointed out.

I'm afraid I'm still concerned about this. The "clean-copy" rule says to remove anything of the form ?subject rdfa:copy ?target, even if there was no ?target with an rdf:type of rdfa:Pattern. It should only be removed if ?target was actually a pattern.

Also, "clean-pattern" would cause any pattern, even if not referenced, to be removed. The original semantics would only remove patterns which were actually referenced.

Maybe these are distinctions the group doesn't actually care about, but we did spend a fair amount of time getting the semantics right; it would be a shame to arbitrarily change them without due consideration.

>> 2. There was a comment elsewhere recently [1] by Lev Khomich 
>> (implementor of RDFa 1.1 extraction in Java): "Also step 1 of 
>> paragraph 3.5.1 may need some explanation for cases of circular 
>> dependencies inrdfa:copy - rdfa:Pattern chains."
>> 
>> Given the set nature of triples and the text "until no new triples
>> are added", I suppose that, technically, circular rdf:copy chains
>> aren't a problem with these rules? Still, it would be wise to spell
>> this out explicitly. (Did Gregg's text do that?)
> 
> I added some warning text in a note.

The word "naive" in the note is a bit pejorative. Perhaps "simplistic"? Also, many implementations can rely on graph semantics rather than specifically tracking triples. If I add a triple to a graph which already contains that triple, the net is that no new triple is added. In my case, I can simply do the following

While graph.count != old_count
  Execute "pattern-copy"
  old_count = graph.count
end

>> ## Some mainly editorial issues
>> 
>> 3. There are several Turtle examples in the document (which I think
>> is good), but no mention of Turtle nor any link to its definition.
>> We should add something akin to (or reference) the Turtle section in
>> RDFa Core [2] (but possibly with a reference to the spec in
>> development [3]).
> 
> Done.
> 
>> 4. Should the results of the first RDFa markup example in "2.1 
>> Document Conformance" really be presented in a table? I'd prefer it
>> in Turtle notation as well (like the rest of the output examples):
>> 
>> @prefix : <http://schema.org/> .
>> 
>> [] a :Blog; :url <http://example.org/> . (By doing this, we don't
>> need the named bnode "_:item1", which could otherwise confuse those
>> who wonder where that comes from.)
> 
> Fixed, although I question the clarity of [] vs _:item1 for someone
> unfamiliar with TURTLE. :P
> 
>> 5. It may be wise to add an explicit output example from "EXAMPLE 6: 
>> Events with duplicate properties" and "EXAMPLE 7: Copying common 
>> properties" in 3.5 as Turtle. Since it is the same for both, only
>> one block is needed:
> 
> Done.
> 
>> 6. As previously pointed out, the word "item" or "items" is used to 
>> describe Pattern copying. Since there are no "RDFa items", only 
>> descriptions of resources (which are post-processed by this
>> mechanism and not "in" the document) I suggest to also change:
>> 
>> * "many items on a page that share a common set of properties" to 
>> "many resources described by a page that share a common set of 
>> properties".
>> 
>> * "This pattern can then be copied into other RDFa items within the 
>> document" to "This pattern can then be copied into other
>> descriptions expressed by the document".
>> 
>> * "The common properties are copied into each event item via the 
>> rdfa:copy predicate" to "The common properties are copied into each 
>> event description via the rdfa:copy predicate".
> 
> Fixed.
> 
>> 7. The text "The inclusion process is iterative, so that resources
>> may include other resources that include other resources." seems 
>> confusing, as we speak about pattern *copying*. It could be changed
>> to "The copy process is iterative, so that patterns may copy other 
>> patterns (that may copy other patterns).". If so, "EXAMPLE 8: 
>> Resources may include other resources that include other resources" 
>> should be renamed accordingly to "EXAMPLE 8: Patterns may copy other 
>> patterns".
> 
> Fixed.
> 
>> 8. While I'm being pedantic, "EXAMPLE 9: Iterative copying example 
>> output in TURTLE" could be improved by using a default prefix
>> (easier to read and more like @vocab), and a non-wrapping top bnode:
>> 
>> @prefix : <http://schema.org/> .
>> 
>> [] a :Person ; :name "John Lennon"; :band [ a :MusicGroup; :name "The
>> Beatles"; :size "4" ] .
> 
> I stayed away from doing this in all of the examples since what's going
> on isn't immediately obvious to somebody that doesn't know Turtle.
> 
>> ## Some syntax issues in the examples
>> 
>> 9. The Turtle in "EXAMPLE 3: Namespace preservation triple" needs 
>> triple quotes for the multiline literals, and to have the datatype
>> IRI put in angle brackets. It should be:
>> 
>> <> <http://example.org/vocab#markup> """<rect
>> xmlns=\"http://www.w3.org/2000/svg\" width=\"300\" →height=\"100\"
>> style=\"fill:rgb(0,0,255);stroke-width:1; stroke:rgb(0,0,0)\"/> 
>> →<rect xmlns=\"http://www.w3.org/2000/svg\" width=\"50\" 
>> →height=\"50\" style=\"fill:rgb(255,0,0);stroke-width:2; 
>> →stroke:rgb(0,0,0)\"/>"""^^<http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>
>> 
>> 
> .
>> 10. The same goes for "EXAMPLE 5: Namespace element preservation 
>> triple". It should be:
> 
> Wow, good eyes. That mistake has been in there for years.
> 
> Fixed.
> 
>> 11. In "EXAMPLE 8", the first <p>-element isn't properly closed,
>> just followed by another <p>. (Granted, HTML5 parsing would fix that;
>> but still.)
> 
> Fixed.
> 
> Thanks, eagle-eyes. :P :)
> 
> -- manu
> 
> -- 
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Aaron Swartz, PaySwarm, and Academic Journals
> http://manu.sporny.org/2013/payswarm-journals/

>

Received on Tuesday, 29 January 2013 20:17:42 UTC