Re: Signalling entailment in queries

On Aug 1, 2010, at 3:29 PM, Sandro Hawke wrote:

>> Right. I thought (1) was off limits, but (2) is what we've been discussing.
>> 
>> Of course, this leaves open the issue of naming of named graphs that have entailment... I'm still not sure how your suggestion of renaming graphs with entailment would work out in practice in a lot of implementations.
>> 
>> .greg
> 
> I withdrew the 'renaming' proposal when I was reminded that in many entailment regimes (eg ones with disjunction) there is not a graph that sensibly contains all the entailments.

Ah, sorry. I was traveling during part of this discussion and must have missed that when trying to catch up.

> My concern then returns to whether SD for ER makes sense.  Kendall says pellet server has its own SD they are happy with, for ER, so that makes me fairly optimistic.   Probably the SD modeling following on the update modeling (cf friday's telecon) will help.  I would like to make sure its described in a way that doesn't rule out parameterized inference.   So, something like 'the default ER for queries on graph G and endpoint EP is E.   So, it's a ternary relation.   I guess the leading approach to those is to reify them, coming up with a name for the relationship.  Perhaps an EntailmentBinding, which has three properties: endpoint, graph, and entailmentRegime.   This is for the named graphs, and the term graph is meant to be understood in that 'slot' sense.

Perhaps I'm still misunderstanding your concern, but it sounds to me like the current modeling does express that ternary relationship:

:service sd:defaultDatasetDescription [
	sd:namedGraph [
		sd:name <graph-name> ;
		sd:entailmentRegime ent:RDFS ;
		# description of graph goes here...
	]
]

If that doesn't address your concerns, could you show an example of the modeling you'd like to see (I find the english description harder to understand than a short turtle example).

.greg

Received on Sunday, 1 August 2010 19:58:00 UTC