Re: ACTION Bijan: to work on "closeOver" work-alike with

On Mar 7, 2005, at 2:09 PM, Dan Connolly wrote:

> 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've updated the file with a few more constraints and some annotations  
to help explain the classes.

> 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

It was meant, I believe, to be the same. Updated.

>>>> 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.

Ah, ok. That's a little more general. I won't claim victory yet, then.

> Then, provided that investigation shows straightforward results, we
> would put it in the SPARQL protocol (and service description) spec
> begin to standardize it.

Sure thing. I was thinking of that as a separate action, but s'ok.

>> 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?

I will think about it.

>> 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.

Sorry, I meant the instance level discovery stuff. If expressivity is  
represented as a relation, then it's a bit hard to see how to avoid  
hasValue. If they are represented as classes, then it's easy. I hope  
this bit is helpful for making some instance level decisions.

>>> 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.

Cool.

> 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.

Ok. I'm fine with pushing it forward.

>>  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...
[snip]

I'm fine working on it with Kendall. I'm unclear if Steve wants to  
spend more cycles on it before it comes back to the group. If not, then  
we should close our current action and open a new one. I guess. It  
depends on how clear about assignments you want to be.

Cheers,
Bijan.

Received on Monday, 7 March 2005 20:25:21 UTC