Re: Potential text for time-permitting features in F&R

Hi Birte,

Birte Glimm wrote:
> Ivan,
> sorry for answering late. My only problem with RDF based semantics is
> that it is not clear to me how this can be done properly with logical
> entailment rather than graph matching. In my understanding, you could
> either use SPARQL as it is now (with graph matching) to query OWL
> ontologies or for something closer to the entailment semantics, you
> would have to complete the graph with possibly an infinite number of
> new triples, which is not really feasible. It could work for the RL
> profile, so that might be something to start with. I am not opposed to
> mention both semantics since it is time permitting anyway, 

I think we can all agree on this. Ie, adding to the list does not do any
harm, leaving it out now might backfire later. We should not make a
decision today because we do not have a good answer right now...

>                                                             but the
> direct semantics is achievable IMHO, whereas I have doubts about the
> RDF based one, apart for OWL RL.

I do believe that we have to say something about RDF based semantics in
general. There are numerous applications out there that rely on
unrestricted usage of OWL (a.k.a. OWL Full) but which may not be OWL RL.
I am not sure, for example, that SKOS is in OWL RL, though it is, as far
as I know, not in the DL subset of OWL.

Actually, it would not necessarily shock me if the definition would be
such that, theoretically, the complete graph would yield an infinite
number of triples. If that theoretical possibility is either of a low
probability in practice, or if there can be some sort of a general
description of patterns that may lead to that, it is all right with me.
What this would still mean is that in the large majority of cases this
would still be perfectly usable in practical cases.

(I know that I am on a slippery ground here because I am not an expert
on how and where this could happen...:-(

Ivan

> Birte
> 
> 
> 2009/6/25 Ivan Herman <ivan@w3.org>:
>> Birte,
>>
>> I think you are right, technically, but that might raise some
>> unnecessary questions from the community  both the direct and the rdf
>> based semantics are not explicitly addressed (even if the rdf based
>> semantics turns out to be just the same as the current one, but that has
>> to be said explicitly somewhere). B.t.w., the same could be said about
>> RDF Schema, does it need a different query semantics? I am not sure...
>>
>> Ie, I would rather say:
>>
>> [[[
>> [...] Time-permitting, the SPARQL WG will use the existing framework to
>> define the semantics of SPARQL queries for one or more of these
>> entailment frameworks:
>> + OWL 2 with both Direct and RDF Based Semantics, including OWL 2 profiles
>> + RDF Schema
>> + RIF rule sets
>> ]]]
>>
>> Another issue I have is with RIF Rule sets, (I would leave Axel to say
>> that): I would have thought that only RIF Core and RIF BLD dialects are
>> really o.k. with SPARQL. I do not believe that RIF PLD would be a
>> reasonable candidate...
>>
>> Ivan
>>
>> Birte Glimm wrote:
>>> Lee,
>>> thanks for the work. I would suggest to rephrase OWL dialects into
>>> profiles because that is the official name used in the OWL 2 spec (I
>>> guess that is what you mean by dialects) and I would like to mention
>>> direct semantics here because the RDF semantics of OWL does not really
>>> need a different entailment regime as I understand it, e.g.:
>>>
>>> [...] Time-permitting, the SPARQL WG will use the existing framework
>>> to define the semantics of SPARQL queries for one or more of these
>>> entailment frameworks:
>>> + OWL 2 with Direct Semantics including OWL 2 profiles
>>> + RDF Schema
>>> + RIF rule sets
>>>
>>> Birte
>>>
>>> 2009/6/25 Lee Feigenbaum <lee@thefigtrees.net>:
>>>> This is to discharge my action at
>>>> http://www.w3.org/2009/sparql/track/actions/49
>>>>
>>>> The goal here is to have enough text that explains what the time permitting
>>>> features are in a way that:
>>>>
>>>> 1) is comprehensive enough to help us build out phase II charter
>>>> 2) will be re-usable / extendable in future versions of the F&R document
>>>>
>>>> To this end, I've tried to do a "Motivation" and brief "Description" for
>>>> each.
>>>>
>>>> Please comment on this, _especially_ if you are not comfortable with any of
>>>> this for the FPWD. We are _not_ going to spend time on this specific text on
>>>> Tuesday before deciding to publish a first public working draft unless there
>>>> are concerns that we have not managed to work out between now and then on
>>>> the mailing list.
>>>>
>>>> Kjetil or Alex, can you please work this into the editor's draft?
>>>>
>>>> Also - please note that we may need to refine the description of common
>>>> functions that is a time-permitting function before publishing the phase ii
>>>> charter, as per ISSUE-2 (http://www.w3.org/2009/sparql/tracker/issues/2). We
>>>> can do this following publication of FPWD of F&R.
>>>>
>>>>
>>>> ~~BGP extensions for entailment regimes~~
>>>>
>>>> -Motivation-
>>>>
>>>> Many software systems that support entailment regimes such as OWL dialects
>>>> and RDF Schema extend the semantics of SPARQL Basic Graph Pattern matching
>>>> to apply to entailments other than simple entailment. The formal semantics
>>>> of these SPARQL/Query extensions are not standardized, and query writers
>>>> cannot currently be guaranteed interoperable behavior when working with
>>>> multiple query engines that extend SPARQL with the same entailment regime..
>>>>
>>>> -Description-
>>>>
>>>> SPARQL/Query 1.0 defines a mechanism to adapt SPARQL to entailment regimes
>>>> beyond simple entailment by providing necessary conditions on re-defining
>>>> the meaning of SPARQL Basic Graph Pattern matching. Time-permitting, the
>>>> SPARQL WG will use the existing framework to define the semantics of SPARQL
>>>> queries for one or more of these entailment frameworks:
>>>>  + OWL dialects, including OWL DL
>>>>  + RDF Schema
>>>>  + RIF rule sets
>>>>
>>>>
>>>> ~~Property paths~~
>>>>
>>>> -Motivation-
>>>>
>>>> Many classes of query over RDF graphs require searching data structures that
>>>> are hierarchical and involve arbitrary-length paths through the graphs.
>>>> Examples include:
>>>>
>>>>  * Retrieving all the elements of an RDF collection (structured as a linked
>>>> list)
>>>>  * Retrieve all of the names of people linked to me transitively via the
>>>> ex:mother and ex:father relationships (i.e. all my known ancestors)
>>>>  * What are all of the direct and indirect superclasses of a given
>>>> owl:Class?
>>>>
>>>> -Description-
>>>>
>>>> SPARQL/Query 1.0 can express queries over fixed-length paths within RDF
>>>> graphs. SPARQL/Query 1.0 can also express queries over arbitrary but
>>>> bounded-length paths via repeated UNION constructs. SPARQL/Query 1.0 cannot
>>>> express queries that require traversing hierarchical structures via
>>>> unbounded, arbitrary-length paths.
>>>>
>>>> Time-permitting, the SPARQL Working Group will define the syntax and
>>>> semantics of property paths, a mechanism for expressing arbitrary-length
>>>> paths of predicates within SPARQL triple patterns.
>>>>
>>>>
>>>> ~~Basic Federated Query~~
>>>>
>>>> -Motivation-
>>>>
>>>> SPARQL is a concise query language to retrieve and join information from
>>>> multiple RDF graphs via a single query. In many cases, the different RDF
>>>> graphs are stored behind distinct SPARQL endpoints.
>>>>
>>>> -Description-
>>>>
>>>> Federated query is the ability to take a query and provide solutions based
>>>> on information from many different sources. It is a hard problem in its most
>>>> general form and is the subject of continuing (and continuous) research. A
>>>> building block is the ability to have one query be able to issue a query on
>>>> another SPARQL endpoint during query execution.
>>>>
>>>> Time-permitting, the SPARQL Working Group will define the syntax and
>>>> semantics for handling a basic class of federated queries in which the
>>>> SPARQL endpoints to use in executing portions of the query are explicitly
>>>> given by the query author.
>>>>
>>>>
>>>> ~~Commonly Used SPARQL Functions~~
>>>>
>>>> -Motivation-
>>>>
>>>> Many SPARQL implementations support functions beyond those required by the
>>>> SPARQL/Query 1.0 specification. There is little to no interoperability
>>>> between the names and semantics of these functions for common tasks such as
>>>> string manipulation.
>>>>
>>>> -Description-
>>>>
>>>> Time-permitting, the SPARQL WG will define URIs and semantics for a set of
>>>> functions commonly supported by existing SPARQL implementations.
>>>>
>>>> See Working Group issue: ISSUE-2 -
>>>> http://www.w3.org/2009/sparql/tracker/issues/2
>>>>
>>>>
>>>> ~~Query language syntax~~
>>>>
>>>> -Motivation-
>>>>
>>>> Certain limitations of the SPARQL/Query 1.0 language syntax cause
>>>> unnecessary barriers for learning and using SPARQL.
>>>>
>>>> -Description-
>>>>
>>>> Time-permitting, the SPARQL Working Group will consider extending
>>>> SPARQL/Query's syntax to include:
>>>>  + Commas between variables and expressions within a SELECT list
>>>>  + IN and BETWEEN operators to abbreviate disjunction and comparisons within
>>>> FILTER expressions
>>>>
>>>>
>>>> Lee
>>>>
>>>>
>>>
>>>
>> --
>>
>> 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