Re: Gathering issues for F2F

Lee,
if there is time to discuss entailment regimes, I would suggest the following:

1) Do we want an extension to the service description document such
that one can specify entailment regimes per graph and not just per end
point. As Andy pointed out, this can be very useful for example to
query for direct subclasses or direct plus indirect subclasses, which
is otherwise not possible under RDFS (and OWL etc) entailment because
under entailment you no longer know what is a direct and what is an
indirect subclass (same for properties). For that you need simple
entailment. For OWL that could also be very useful to query for
annotations and labels since these are not entailed and can also only
be queried by simple entailment.

2) Is there a broad consensus for the consistency check requirements
as they are now: If the queried graph is RDFS-inconsistent, an
implementation MAY generate an error or warning and SHOULD generate
such an error or warning if, in the course of processing, it
determines that the data or query is not compatible with the request.
the other option would be that systems MUST generate an error in case
the queried graph is inconsistent, which comes at a higher cost, but
is more consistent with RDFS entailment as defined in the spec.

3) It is not clear how RIF entailment regimes should be specified. One
could consider each rule set as an entailment regime and have a
description such as
   myEndpoint sd:EntailmentRegime
<http://example.org/myCustomEntailmentRules.rif>
in a service description or one would have to specify rule sets in a
from clause (but rules are not representable in RDF) in which case one
can also only combine rules and data by having several from clauses or
by having import statements in the rules file.

4) The absence of import statements in RDF(S) makes it necessary to
use several from clause to create a fresh default graph whenever one
wants to combine triples from different sources, e.g., if I want to
use my data with FOAF as a kind of schema. We can either just live
with this or we might want to think about a suitable language
extension.

There might not be time for all this, but I thought I suggest it anyway.
Birte


2009/10/20 Seaborne, Andy <andy.seaborne@hp.com>:
> Steve and Andy came up with a list of things that might be usefully discussed F2F,
>
> 1/ How does the algebra of query fit with SPARQL/Update?
>
> Query and update are linked - does update bring any issues to matching the two conceptual models?  What about datasets and graph stores?
>
> 2/ Test cases: process and practice for capturing designs in test cases and building up a test suite.
>
> 3/ Sort through issues list and make sure the wording makes sense.
>
> The issues can be a little hard to understand after time has passed.  By being face-to-face, it would be a chance to refine the wording in the light of the time since the issue was first added.
>
> 4/ Language tags.
>
> SPARQL filters do not require implement understanding of languages tags.  Is this a good thing or should it be changed?  At the moment it's an error and an extension point but RDF has language tags so graph matching already takes it into account.  (see recent sparql-dev).
>
>        Andy
>
>



-- 
Dr. Birte Glimm, Room 306
Computing Laboratory
Parks Road
Oxford
OX1 3QD
United Kingdom
+44 (0)1865 283529

Received on Friday, 23 October 2009 14:17:45 UTC