- From: Ivan Herman <ivan@w3.org>
- Date: Thu, 4 Aug 2011 22:35:47 +0200
- To: Gregg Kellogg <gregg@kellogg-assoc.com>
- Cc: W3C RDFWA WG <public-rdfa-wg@w3.org>
Gregg, I will look at it tomorrow, it is a bit too late for me here. But, I presume, when you use the term 'member submission' it is not like a 'real' W3C member submission http://www.w3.org/Submission/ but simply a text for the RDFa specification, right? Why using github and not our usual place to edit things, like our wiki page or our CVS space? It becomes a bit complicated if our different documents are spread all over the place... Not that it is sooo important, of course, just to organize ourselves...;-) more below On 4 Aug 2011, at 20:10, Gregg Kellogg <gregg@kellogg-assoc.com> wrote: > Ivan, we actually created a GitHub repository for this as a member submission: https://github.com/rdfa/ms-proxy-vocab. This might be a good place to add this text, along with the motivation. (It was on my list of things to do, thanks for jumping on this). > > More below: > On Aug 4, 2011, at 9:33 AM, Ivan Herman wrote: > >> Guys, >> >> I have had a long discussion with Manu today, and we both agreed that, in view of all the issues surrounding RDFa and its future, it would be good to 'spec' the proxy feature as soon as possible to move ahead. I had a very first stab at it, which is clearly not spec quality but at least gathers my thoughts on how this thing could be specified relatively quickly and succinctly. My goal was to try to minimize what *we* should specify and, rather, rely on existing specifications. We may want to check that with some people who are good at semantics. >> >> Here it is. >> >> Cheers >> >> Ivan >> >> >> [[[ >> <h1>RDFa Vocabulary Expansion</h1> >> >> Once the default graph is generated following the processing steps defined at @@LINK@@, RDFa processors MAY (or SHOULD?) perform the following processing steps on the default graph. >> >> - For all URI-s that appear as a value of a @vocab attribute in the RDFa source, that URI is dereferenced. If the dereferencing yields the serialization of an RDF graph, that graph is merged with the default graph. (RDFa processor MUST accept an RDF graph serialized in RDFa, SHOULD accept an RDF graph serialized in RDF/XML[REF] or Turtle[REF], and MAY accept other serialization formats of RDF.) > > Need to guard against recursion here. At least to abort an attempt to import a graph that is already in the process of, or has already been imported. Yes. But that is an implementation issue in my view. I am not sure this is something for the specification. > >> - The processor expands the default graph using the RDFa Vocab Entailment @@@Link to section below@@@. >> >> <h2>RDFa Vocab Entailment</h2> >> >> <h3>RDFa Vocab Entailment definition (normative)</h3> >> >> For the purpose of vocabulary processing, RDFa uses restricted version of the full RDFS entailment[1]. This entailment is based on a restriction of the vocabulary used by the RDFS Interpretation[2]. Indeed, the RDFa vocab entailment vocabulary contains only the following terms: >> >> - rdf:type rdfs:subClassOf rdfs:subPropertyOf >> >> and the RDFa vocabulary entailment does not use any of the axiomatic triples defined in [2] or [3]. > > We had also discussed that datatype coercion would be something that a proxy vocabulary might accomplish, however, as I mentioned, I don't think this can be done through normal entailment regimes. It may, but it is hairy. Datatype entailment, mainly if we bring in OWL 2 RL can go a long way, but I do not think we should go there. We can of course include range and domain into the vocabulary, and let RDFS go to get literals get a specific type, and then make a datatype coersion based on that. But I am reluctant go go there. Datatype entailment can be tricky (issues with literals as subjects, etc). > It's also a theme in recent Microdata-RDF discussions [5] which have a similar issue. @itemvaltype is not universally loved, and it's questionable how much @datatype is used properly in RDFa. Clearly, being able to use some combination of rdfs:range and lexical value space could be useful in reproducing this, but it would seem to need to be done at processing time, not after the fact. > > If we could solve this issue, it would be useful across all RDF serializations where publishers are often lazy about using typed literals. > In fact, what we can say is that RDFa processors can perform other entailments, too, including OWL 2 RL. Let implementations fight on that; we should concentrate on the minimum, ie, a replacement of profiles. I am a bit concerned about trying to do too much... Cheers Ivan >> <h3>RDFa Vocab Entailment Rules (informative)</h3> >> >> While the formal definition of the RDFa Entailment is defined in terms of RDF Semantics, practical implementations may rely on the (informative) entailement rules published in the RDF Semantics documents[4]. In particular, the relevant rules are (using the rule identification in [4]): rdfs5, rdfs7, rdfs9, and rdfs11. >> >> <h2>Vocabulary Expansion Contol of RDFa Processors</h2> >> >> Comforming RDFa processors are <em>not</em> required to provide vocabulary expansion. >> >> If an RDFa processor provides vocabulary expansion, it MUST NOT be done by default. Instead, the processor must provide an option, <tt>vocab_expansion</tt>, which, when used, instructs the RDFa processor to perform a vocabulary expansion before returning the default graph. >> >> >> [1] http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#rdfs_entailment >> [2] http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#rdfs_interp >> [3] http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#InterpVocab >> [4] http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#rules >> ]]] >> >> >> ---- >> 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 > > Gregg > > [5] https://plus.google.com/112095156983892490612/posts/aUqGQSLzDPv >
Received on Thursday, 4 August 2011 20:33:29 UTC