semantics of dataset predicates

On 09/26/2012 12:59 AM, Pat Hayes wrote:
> On Sep 25, 2012, at 9:25 PM, Sandro Hawke wrote:
>
>> On 09/25/2012 09:54 PM, Pat Hayes wrote:
>>> On Sep 25, 2012, at 5:16 PM, Sandro Hawke wrote:
>>>
>>>
>>>> For myself, at this point I'm 70% convinced that I can implement all the dataset use cases I understand (the ones I enumerated in the Federated Phonebook examples, plus SPARQL dump/restore) without any standard dataset semantics beyond having a standard place for metadata (eg the default graph in trig and the service description graph in SPARQL).
>>>>
>>> Sandro, how can you use metadata *at all* without some way to force a URI to denote a graph? When you use the URI in the metadata RDF, what (semantic or even pragmatic) constraint ensures that what it denotes there is the graph that you have in mind? Or indeed, that it is a graph at all?
>>>
>> My current theory is that I can do it via the documentation of the predicate(s) I use with that URI.
> Hmm. But the semantics being discussed right now explicitly distinguishes the graph "named" by the URI it is attached to in a dataset, from the entity the URI is understood to denote. And the RDF semantics says that when a URI is used in an RDF triple, it refers to what it denotes. So your documentation seems, on the face of things, to be at odds with what the semantics says.

On the face of it, perhaps, because of what you're reading into the 
informal language I used.  Let me see if I can be somewhat more formal 
without stepping in over my head:

    X eg:sendCorrectionsTo Y


is defined by:

    In an RDF Dataset <DG, <U0,G0>, <U1, G1>...> if an RDF triple in DG
    matches the graph pattern {?X eg:sendCorrectionsTo ?Y} and ?X = Ui
    for some i, then ?Y is a socially appropriate email address to which
    one may send corrections to any information expressed in Gi.

My hope is that RDF Concepts 1.1 will define terminology such that I can 
instead say that in a much more readable form, such as:

    { X eg:sendCorrectionsTo Y } means that Y is a good email address
    for sending corrections to the information in the named graph X.


I know this definition sort of flouts the RDF Semantics, because it 
defines eg:sendCorrectionsTo in terms of the URI X, itself, instead of 
I(X).  But it seems to be perfectly workable, and I think also has a 
coherent reading in line with the RDF Semantics and some Semantics of 
Datasets -- even if it's not one this group can see/agree on.

In particular, I'm perfectly comfortable with inference being done with 
eg:sendCorrectionsTo.   In my head, when I construct various OWL 
constructs using X, Y, or eg:sendCorrectionsTo, and do OWL inference, I 
haven't noticed any counter-intuitive results.

> The basic point is, you can specify what your property means, but you don't get free rein to say what the graph "name" URI refers to. (At least, not unless you have something like a context to put it in, where you *could* say what it means.)

Yeah, formally, for now, I'm ignoring what the URI X might refer to, and 
just using X itself.

I know that's not Kosher, but I'm at a loss to find an actual problem 
with it.   Model theory is one way to describe coherent system behavior, 
but if I can express that coherent system behavior in other ways, that's 
okay too.   Hopefully we'll converge back on model theory, when you see 
how to use it to explain what I'm trying to do.

Let's see how far I can go with this.   We'll start with another predicate:

    { ?X eg:userProfile ?Y } means that ?X is a foaf:Person and the
    triples of their user profile are in named graph ?Y

which seems fine to me, then let's twist that into the admittedly-crazy 
usage we sometimes use as an example, where a foaf:Person URI is used as 
the graph-label in a dataset for the their profile info.   So, we get 
something like this:

    { ?X rdf:type eg:PersonAndProfileLabel } means that ?X denotes a
    foaf:Person and the triples in that person's user profile are in the
    named graph ?X.

Speaking as a software engineer, I think that probably works.  I'm 
pretty sure coherent code can be written to work with that class, even 
in the presence of various kinds of reasoning.   I'd need a day or two 
of coding to get that to "quite sure", and I'd probably do a few tweaks 
along the way.

        -- Sandro

> Pat
>
>
>>   Given the emerging sense of what datasets are, I think I can write that document in such a way that it will be quite clear to human readers (and thus the software they write) how it connects to the triples in the named graphs.
>>
>> I'm hoping the WG will end up making it really easy to write that documentation, but I'm pretty sure it's possible anyway.
>>
>> The example I used in [1] was:
>>
>>      <g1> eg:sendCorrectionsTo <mailto:sandro@w3.org
>>> .
>>      <g1> { w3c:group35462 rdfs:label "SPARQL Working Group" }.
>>      <g2> eg:sendCorrectionsTo <mailto:
>> ivan@w3.org
>>> .
>>      <g2> { w3c:group44350 rdfs:label "RDFa Working Group" }.
>>
>> (I'm using the default graph for metadata, and leaving off the braces around default-graph triples)
>>
>> And then I proposed documenting eg:sendCorrectionsTo something like this:
>>
>>      X eg:sendCorrectionsTo Y
>>
>>          Note: only meaningful as metadata for a dataset which has a named graph
>>          with the name X.
>>
>>          Meaning: Y is a good email address for sending corrections to
>>          the information in the named graph X.
>>
>>
>> This definition doesn't really care whether named graphs are g-boxes or g-snaps, but I think it's probably good enough to work in practice.   Other predicates might be much more precise, of course.
>>
>> I'm not thrilled with the predicate being only meaningful when used in a dataset metadata [I prefered my framing as rdf-spaces] but this works, too, I think.
>>
>>          -- Sandro
>>
>> [1] http://lists.w3.org/Archives/Public/public-rdf-wg/2012Sep/0181.html
>>
>>> Pat
>>>
>>>
>>>>     -- Sandro
>>>>
>>>> [1]
>>>> http://www.w3.org/2005/10/Process-20051014/tr#cfr
>>>>
>>>>
>>>>
>>>>
>>> ------------------------------------------------------------
>>> IHMC                                     (850)434 8903 or (650)494 3973
>>> 40 South Alcaniz St.           (850)202 4416   office
>>> Pensacola                            (850)202 4440   fax
>>> FL 32502                              (850)291 0667   mobile
>>> phayesAT-SIGNihmc.us
>>> http://www.ihmc.us/users/phayes
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
> ------------------------------------------------------------
> IHMC                                     (850)434 8903 or (650)494 3973
> 40 South Alcaniz St.           (850)202 4416   office
> Pensacola                            (850)202 4440   fax
> FL 32502                              (850)291 0667   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>
>
>
>
>
>

Received on Wednesday, 26 September 2012 12:38:14 UTC