Re: thoughts on the profile issue

On Aug 2, 2011, at 6:48 AM, "Ivan Herman" <ivan@w3.org> wrote:

> Wow:-) Many things have happened while I was on vacations...
> 
> This mail is set of slightly random thoughts on the profile discussion. Instead of answering each individual mails, I would rather gather my thoughts at one place; it may also help in triggering new discussions. I am sorry it is fairly long... Bear with me!
> 
> ...
> 
> 4. The RDFa-Sem alternative _is_ interesting. What Niklas is saying (if my understanding is correct) is that a URI used for a @vocab _may_ be a reference to an RDFS vocabulary; so an RDFa processor may pick up all the RDFS vocabularies in the file, merge all these graphs, and do an RDFS reasoning on the merged graph. Just follow the RDFS semantics' document! In this sense, the usage of map:ProxyProperty is actually superfluous: by virtue of the RDFS semantics subPropertyOf, for example, should suffice. There are some details to handle (which version of the RDFS reasoning would one use), but that can be done.

Nilklas and I had in mind to create a member submission on this topic, given the time to do so.

One difference between general RDFS reasoning, and proxy reasoning, is the potentially open-ended nature of general RDFS reasoning. That is, inference steps may need to be repeated until no further triples are generated. The proxy mechanism should be defined in terms of SPARQL updates that only need to be executed once per rule. Also, I'm not clear on how range inference might set the datatype of a literal without generating a new triple.

> Note that Niklas had a very reduced RDFS handling in mind, essentially exploiting subPropertyOf and subClassOf only. But why stopping there, why not exploiting, for example, range and domain statements? (Ok, I may ask too much here:-)

owl:sameAs, equivalentProperty, ... might be more appropriate. But, in general, I think this is correct, as long as it is in a fixed number of processing steps.

> So yes, that is an interesting line. Of course... implementing the full RDFS, though possible, is comparable in complexity to the management of profiles (though, with the expected size of an RDF graph in an RDFa file, a very simple, straightforward forward chaining reasoner would do the trick. But handling blank nodes in literals in an RDFS reasoner is still a bit tricky). I am wondering:  how many implementations will there be around that would produce not only the basic RDF graph, but the extended one as well? (We have several implementers around!) Note that a similar caching mechanism as the one discussed for profiles would be necessary to really make a good job.
> 
> (I would do it. O.k, I have the advantage of having implementd an RDFS reasoner in the past in Python, so...)
> 
> 5. If I am a user doing, say, SPARQL on the output of an RDFa processor, what would I query?
> 
> - If RDFa uses @profile, would my query rely on all terms and prefixes/uris that are defined through @profiles? I think yes. Indeed, the question here is: what is the probability of failing to get a profile file and therefore missing out triples? Here comes Shane's argument: the probability is very small, in fact. There won't be many profiles around, kosher RDFa processors would cache those anyway, so in a majority of the cases we could rely on all, expanded terms and URI-s.
> - If RDFa uses RDFa-Sem, would my query rely not only on the core terms with the @vocab value but _also_ on the RDFS expanded terms? Well... not unless managing the RDFS reasoning is mandatory in the RDFa processor! Of course, if it is, then the same arguments apply as for profiles: there won't be that many @vocab-s with RDFS statements out there, kosher RDFa-Sem processors would cache those anyway, etc.
> 
> So: is RDFa-Sem mandatory? Because if not, then users may rely on those terms only if they use their own RDFa processors, or environments that have RDFS processing built in. And here is the catch: unfortunately, at the moment, not many RDF environment have RDFS processing built in, out of the box (eg, RDFLib does not have that). 

IMO, not mandatory, and simple applications will operate on the @vocab namespace.

Adding this as a SHOULD behavior might actually get RDFS reasoning to become more main stream, and provide a better direction for ontology developers who are tempted to re-create their own versions of standard properties.


Gregg

>  at the moment, I find Niklas' RDFa-Sem proposal appealing and it might be considered as a possible improvement of @vocab that may make @profile unnecessary. Actually, it might make a bridge to the microdata discussion, too; after all, the mechanism would be an extension to what an RDF mapping of microdata does, and that might be good... But it is still unclear to me whether it is realistic go down that line in practice. If this does not work, though, than I would be fairly uneasy about dropping profiles
> 
> Sorry for this looooong mail
> 
> B.t.w.: I think fully using RDFa-Sem this way would really require community feedback. I wonder whether somebody (Niklas? Manu?) could do a, say, Google+ or a blog entry somewhere with the explicit goal of asking for feedback (Google+ seems to be the most active community discussion place these days...)

Good idea.

> Ivan
> 
> 
> [1] http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jul/0048.html
> [2] https://plus.google.com/u/0/112095156983892490612/posts/aUqGQSLzDPv
> 
> 
> ----
> 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
> 
> 
> 
> 
> 
>

Received on Wednesday, 3 August 2011 01:07:39 UTC