Re: Small @profile question

On Sep 10, 2010, at 11:21 , Nathan wrote:

> 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?
> 

You mean the RDFa validator (ie, the HTML validator with RDFa DTD): the answer is yes.

If you mean the real RDF validator, again, that is fine, too, because the RDFa processor will not generate any triple if the CURIE cannot be resolved.

> 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?

It is a bit different because the generated RDF content will not include any of those.

> 
>>> - 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.

No, I think you are right. This may very well happen in theory.

A somewhat similar situation does arise today already, though. If an RDF file refers to an OWL vocabulary, for example, and that vocabulary changes, then the triples that can be deduced will change, too. Actually, if the corresponding OWL or schema file is unreachable, then no triples will be deduced whatsoever. I know it is a different example but just to show that the situation is not completely new...

> 
>> 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.

... and hence those triples will be missing. Your mental model is perfectly o.k. and all what you describe is true. I understand what you mean now...

> 
>>> 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 :)

Nathan, there is absolutely no reason to apologize and I did not take your questions as condescending _at all_! You are absolutely right is asking these questions which do show the potential dangers in using profiles. What we, as a community, have to decide is whether the advantages of using profiles outweight the potential problems or not, and that should decide whether the feature should remain in the final RDFa spec or not. So your questions are valuable for that discussion...

Thanks!

Ivan

> 
> Best,
> 
> Nathan


----
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