- From: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
- Date: Fri, 9 Oct 2009 14:21:05 +0100
- To: Ivan Herman <ivan@w3.org>
- Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
[snip] >> As I understand it, from named can be used to access graphs in the >> data set of the query processor. You can do merges into a fresh >> default graph. Even though this might not be nicest thing in >> particular for some entailment regimes, this is something that needs >> to be addressed in the SPARQL query document. The requirement might >> come from entailment regimes, but entailment regimes are based on >> SPARQL and if SPARQL does not define it, then we cannot use it. I >> personally do not want to raise an issue and a request for that, but >> if others feel like doing it... > > I must say I am a little bit mixed up here, maybe you can help... We discussed the > issues of restricting entailements specific graphs when those graphs are defined through > the named graph mechanism of sparql. But I am now messed up on how the FROM NAMED and > the GRAPH statements would exactly influence entailement, ie when is anything > restricted. Could you try to summarize this for a better understanding? Maybe this is > where my confusion comes from... but I am lost a bit:-( I added a section on this into the entailment regimes doc: http://www.w3.org/2009/sparql/wiki/Design:EntailmentRegimes#Entailment_Regimes_and_Data_Sets but I have the impression that it will not answer your question. Basically, triples in one graph of the data set do not have any influence on any other graph in the data set. For a system supporting RDFS entailment, for examle, you could take the triples from one RDF document, load it into graph A, built a partial RDFS closure (using the ter Horst algorithm) and answer queries by using simple entailment on the partial RDFS closure. Now if you additionally load the triples from another RDF document into graph B, then this has no influence on graph A, so even if graph A contains :a rdf:type :B . (inferred or stated in the originally loaded document) and the document loaded into graph B contains :B rdfs:subClassOf :C you cannot use this to get :a rdf:type :C . as a query answer from graph A. The triples in one graph are not visible in another graph. I am not quite sure what you mean with "restricting entailments specific graphs". Do you have in mind that a query processor provides a certain data set description, say with some default graph, graph A, and graph B, and one of the named graphs, say A, is for queries with RDFS entailement, while the other one (B) is for queries with simple entailment? At the moment that would not be possible in my understanding and, in general, the ways of choosing what entailment regime you want seems not very flexible (but I might overlook something). Let us assume you have a query processor that can do simple, RDF, and RDFS entailment (not too unreasonable I think). As I understand it, that would mean that you can have three endpoints, one for each entailment regime and depending on which endpoint I choose when I query, I get one of the three entailment regimes and I can ask that endpoint via service descriptions what data sets it has etc. What we cannot do at the moment (if I understand it correctly) is to mix entailment regimes in one endpoint, so you cannot say the your query should contain results from graph A under RDFS entailments unioned/joined with results from graph B for the graph B results you want simple entailment. There is no way to specify that in the query and there is no way for an endpoint to communicate that it will use simple entailment for some data set and RDF(S) for another. Provided I get that right, I am not sure how much of an issue that is. I can live with it, but that is my personal opinion. For OWL I can see just what you mention above as something that needs to be addressed, i.e., how can users query for things that are not entailed, but are stated in the ontology and that are important to users (annotations most notable, but imports also fall into this category). If we allow some way of specifying in a query that some part of the query has to be evaluated under one entailment regime and other parts of the query under other regimes, that is fine. Then you can use simple entailment for annotations and OWL or whatever for the rest. If we do not want to go that way, we could also define OWL entailment in a way that does not employ OWL semantics to annotation queries. That is not as nice in my opinion, but it would be a workaround that does not require changes in other specs. Birte >> > [snip] >> >>> And what you say is perfectly o.k. in view of the RIF specification. >>> However: in SPARQL, FROM and FROM NAMED are defined to specify RDF >>> datasets. OWL and RDFS are (or can be expressed in) RDF. RIF rules cannot. >>> >>> That actually may create problems for OWL, too. There is no problem if the >>> OWL ontology in the FROM clause is in RDF. But would the spec allow to refer >>> too OWL ontologies in functional and/or Manchester syntax via the FROM or >>> FROM NAMED clauses? >> >> Question to the SPARQL implementors/experts. Can I specify my RDF data >> in turtle and query that in accordance with the spec? If not in >> accordance with the spec, do systems support turtle input? >> If yes, then I cannot see, why not functional or manchester syntax. >> This is obviously not normative. Any system might reject non-RDF-XML >> input, but many systems might happily take it. >> If not even turtle is allowed, are there any plans for doing that as >> an optional syntax? If not, I guess we have to live with RDF XML. That >> would probably be the end for RIF though, for OWL RDF ML is normative >> and any conformant system must support it anyway, so it is not as bad >> for OWL. >> > > Hm (again:-). Yes, you are actually right, I am not sure the spec says anything. My > impression is that the spec is silent at that point and a URI to a graph amy refer to > any format that the processor understands. If that is so, we may not have a problem with > OWL if the processor understands non RDF/XML formats. Maybe it is worth to add this to a > possible service descriptions, though. > > But it is certainly a problem with RIF. Indeed, turtle may not be a standard format but > it is an RDF serialization syntax. In this sense, both the OWL 2 functional syntax and > the M'ter syntax can be considered as an RDF serialization syntax, because they can be > converted, in a standard way, to RDF. But an RIF rule set _cannot_:-( > > Thanks > > Ivan > >>> I would expect we should be able to do that, but that might affect the query >>> language specification. >> >> Again, that is up to the general SPARQL/Query spec and however want to >> raise an issue for that can do so. >> >> Birte >> >>> I remember Axel and I had some corridor chat at some point that would allow >>> adding a media type to the FROM (NAMED) clause... >>> >>> Ivan >>> >>>> Birte >>>> >>>>> Ivan >>>>> >>>>> >>>>> -- >>>>> >>>>> 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 >>>>> >>>> >>>> >>>> >>> >>> -- >>> >>> 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 >>> >> >> >> >> -- >> Dr. Birte Glimm, Room 306 >> Computing Laboratory >> Parks Road >> Oxford >> OX1 3QD >> United Kingdom >> +44 (0)1865 283529 >> > > > -- > Ivan Herman, W3C Semantic Web Activity Lead > URL: http://www.w3.org/People/Ivan/ > FOAF: http://www.ivan-herman.net/foaf.rdf > > -- Dr. Birte Glimm, Room 306 Computing Laboratory Parks Road Oxford OX1 3QD United Kingdom +44 (0)1865 283529
Received on Friday, 9 October 2009 13:21:41 UTC