- From: Nathan <nathan@webr3.org>
- Date: Fri, 10 Sep 2010 10:21:14 +0100
- To: Ivan Herman <ivan@w3.org>
- CC: Shane McCarron <shane@aptest.com>, Gregg Kellogg <gregg@kellogg-assoc.com>, Melvin Carvalho <melvincarvalho@gmail.com>, Mark Birbeck <mark.birbeck@webbackplane.com>, RDFA Working Group <public-rdfa-wg@w3.org>
Hi Ivan, Ivan Herman wrote: > On Sep 10, 2010, at 10:02 , Nathan wrote: >> Succinctly, it is possible to create a valid RDFa document which contains a valid RDF Graph, which, without changing the RDFa Document or RDFa Specification can vary temporally to: >> - become invalid, > > I am not sure that is a possibility. I mean: what do you mean by invalid? The (X)HTML+RDFa will stay valid. The generated RDF (if any) will stay valid. Some CURIE-s may be invalid if this is what you mean, but those will be ignored by the processors (they are allowed to issue warnings or errors). Perhaps that's a question I should ask then, if an (X)HTML+RDFa 1.1 document contains CURIE-s that cannot be resolved, is it still valid when run through a RDF Validator? Is an (X)HTML+RDFa 1.1 document with one or more unresolvable CURIE-s (due to @profiles not being able to be retrieved) to be considered as you would an RDF/XML document with namespaces missing or a Turtle document with missing prefixes? >> - contain a different RDF Graph to that contained in different serializations served via content negotiation. > > I am not sure what you mean by this. I mean that if I have an RDF Graph which I serialize as Turtle, RDF/XML and (X)HTML+RDFa and expose via content negotiation, where all three variants are valid and produce the same set of RDF Triples at Last-Modified time, and where the RDFa variant relies on profiles, then it's possible for the Graph produced by parsing the RDFa Document to vary over time without modifying the file/representation, whilst not-so with the other two variants. If this is wrong then please do correct me. > It can happen, in very rare cases, that the generated graph is different. This is when a profile is expected somewhere in the DOM tree that _overrides_ a prefix or a term definition that got a definition somewhere up the tree. I would not expect that to be very frequent. I was thinking more that if I serialize a graph containing 20 triples as (valid) Turtle and (valid) RDFa w/ profiles, then at any point in time the turtle document will always produce those 20 triples when parsed, whereas the RDFa document could produce 0-20 triples whilst remaining valid. Perhaps though I've misunderstood @profile? I'd thought that typically one would store all, or a common set of, prefix->uri maps in a profile document then reference one or more of these profile documents to provide curie resolution for your rdfa document - as in, if you removed all reference to the profile documents then some or all curie-s in your document would not be resolvable. >> Regardless, I trust that the Working Group has weighed up all of the pros and cons, thus making the inclusion of @profiles in RDFa an informed decision made with wide open eyes. As mentioned in my original mail, this was more for my own peace of mind ensuring that the raised points had been fully considered / are not new :) > > Yes, I think we all know that this is the only major change in RDFa1.0 vs. RDFa1.1, all other changes are more cosmetic in nature. And we did have a lot of discussions. But some feedbacks we got from potential RDFa consumers like Facebook seem to indicate that may become a very useful feature nevertheless. I personally also expect that most of the RDFa processors will have some sort of a caching mechanism for the well known profiles, ie, processing the RDFa files will be less dependent on the possible network problems... Sorry Ivan, I really didn't mean to come across as condescending or to cause any offence, was more trying to acknowledge that I think you've all done great work, and even though I'm asking questions, I do trust the decisions you've all made :) Best, Nathan
Received on Friday, 10 September 2010 09:22:23 UTC