- From: Gregory Williams <greg@evilfunhouse.com>
- Date: Wed, 2 Dec 2009 12:16:41 -0500
- To: Ivan Herman <ivan@w3.org>
- Cc: Birte Glimm <birte.glimm@comlab.ox.ac.uk>, SPARQL Working Group <public-rdf-dawg@w3.org>
On Nov 24, 2009, at 1:12 PM, Ivan Herman wrote: > Birte Glimm wrote: >> >> Yes, that would definitely be nice, but I think on the entailment >> regimes telecon we agreed that an exact specification could also be >> left open for now. Systems can add something to their service >> descriptions indication what profile they support, but it is not >> necessarily standardised. Much in the same way as systems already >> support aggregates, but only now the most popular and established >> aggregaton functions are standardised. If Greg wants to add something >> in that direction, I am happy to work on that with him. >> Birte >> > > O.k., let us see how this goes... Personally, I think that adding some > simple vocabulary would be good. Something like > > sd:possibleEntailmentRegime <URI-FOR-Direct-Semantics>, <URI-FOR-SIMPLE>; > sd:possibleEntailmentProfile <URI-FOR-DL>, <URI-FOR-QL>. I assume these together would replace the current sd:supportedEntailment property? Also, I know there had been some brief discussion of the difference between hanging these properties off of the service and off of specific graph descriptions (for cases where different entailment applies to different graphs in the dataset). Would these continue to be terms with sd:Service as the domain? I feel a bit out of my depths with respect to some of the entailment work, but these seem like reasonable things to add to the service description vocabulary. With either these new terms or the existing sd:supportedEntailment term, though, I wonder what I'm supposed to do with this information if I get back multiple values for the possible regimes? I don't currently do a lot of work with reasoning systems, but without a way to request a specific entailment regime for a query, having multiple values for sd:possibleEntailmentRegime seems almost as bad as having zero values as far as the end user is concerned. Is this relevant for anybody's use cases? There's obviously a lot of potential complexity here, but having a useful solution for simple cases would be nice. .greg
Received on Wednesday, 2 December 2009 17:17:10 UTC