- From: Dan Connolly <connolly@w3.org>
- Date: Mon, 07 Mar 2005 13:09:25 -0600
- To: Bijan Parsia <bparsia@isr.umd.edu>
- Cc: DAWG Mailing List <public-rdf-dawg@w3.org>
On Mon, 2005-03-07 at 13:17 -0500, Bijan Parsia wrote: > On Mar 7, 2005, at 12:40 PM, Dan Connolly wrote: > > > On Mon, 2005-03-07 at 10:55 -0500, Bijan Parsia wrote: [...] > >> I do not have a fully worked out proposal, but you can examine the > >> thing we hacked together: > >> http://www.mindswap.org/dav/ontologies/bijan/2005/dawg/TestClosedOver [...] > > To make MyStore closedOver RDFS make it an instance of > http://www.mindswap.org/TestClosedOver#RdfsOnlyStore > > (I'm updating the example file as we speak.) Ah... OK, that makes sense (and I see that connection is in the file now). I wonder how :hasGraph relates to the saddle:dataSet property we discussed... http://lists.w3.org/Archives/Public/public-rdf-dawg/2005JanMar/att-0225/ftf5-desc.txt > >> Right now it uses nominals to represent graphs with different > >> expressivities. [...] > > but it doesn't convince > > me that we should standardize this idiom at this time; > > My action, as I understand it, was to convince Steve that he wouldn't > have to enumerate all his graphs in order to say that they all were > closed over RDFS. I think I have done that. Convincing you that this > idiom should be standardized is a different action I think. Hm... I thought the goal was to figure out what sort of service description would help clients such as the ones you're building, clients that can take advantage of RDFS-happy services (like Steve's) and OWL-happy service like the ones you work on. Then, provided that investigation shows straightforward results, we would put it in the SPARQL protocol (and service description) spec begin to standardize it. > There may not be a need to standardize it at all. There are many > different ways of representing what Steve wants. If we can presume OWL > reasoning, then there's little need to pick and idiom. If we want to > enforce something a little more restrictive, then we might. If it comes down to just picking URIs for terms like :hasGraph and :owl-lite, and explaining a bit about how to use them for this purpose, then very well. These clients that you're building... is that enough for them? > A lot rests on the fleshing out of the discovery stuff anyway. Umm... I thought this was the discovery stuff... i.e. this is how one discovers an RDFS-happy (or OWL-happy...) service. > > i.e. anybody > > who wants it standardized will please flesh out more details. > > I don't see that it's not fleshed, at least in principle. With the > above blanks filled in, what details do you see missing? I think I see how it works, technically, at this point. I suppose what I meant to say is: there's some more relevant work... a few paragraphs in the protocol spec, maybe a test case or two. Maybe Kendall is willing to do much of that. Maybe you are. Maybe Steve is. I prefer to keep it somewhat explicit who has the ball... I wanted to say that this looks fine for what it is, but if we're to put it in the SPARQL spec, somebody should carry the ball a few more yards forward, or at least chime in expressing some willingness to do so. Meanwhile, you have advanced the ball a bit yourself. > The > unfortunate part, from my perspective, is the use of nominals, which is > sort of a consequence of what I remembered to be the instance level > choice of representation. I don't understand that... but I guess I don't need to. What I see looks OK to me. > (Also, there are future issues about, e.g., > relations between expressivity; the difference between supporting > expressivity foo and *only* supporting it (both way! i.e., not > supporting only subsets of the expressivity and not supporting > supersets). I think I can see what you mean by that. I wonder if I'll find time to think about it any more seriously... > > Maybe > > Kendall groks well enough to run with it as is. > > Prolly. > > Cheers, > Bijan. -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E
Received on Monday, 7 March 2005 19:09:26 UTC