Re: Attempt to provide semantics to Sandro's named graph design

On Apr 11, 2012, at 16:41 , Sandro Hawke wrote:
[snip]
>> 
>>> 
>>>> As for the global thing: I think the semantics can go as far as saying that if you use the same label to two different graphs, then you get into an inconsistent situation. 
>>>> 
>>>> Looking at the result: at the moment I do not see any value in the rdf:Graph class! Indeed, none of the semantic conditions make use of it (except of course its definition). And because this semantics *is* fairly weak after all, this may be fine.
>>> 
>>> Maybe you're missing Condition 3?   That uses rdf:Graph.
>> 
>> Yes, but the only thing that condition does is to define what rdf:Graph means. But none of the other condition refer to it; put it another way, all the other conditions are formulated without a reference to the fact that ui is or is not in rdf:Graph. If so, what is the use?
>> 
>>> 
>>> You could make that a bit stronger, too, making it a biconditional.
>>> That is, it is also true that I(ui)=Gi implies {ui rdf:type rdf:Graph}.
>> 
>> Yep, could be done, but does not change what I said...
> 
> I don't understand.   rdf:Graph, just as defined in condition 3, is
> absolutely necessary for some use cases, like providing the dc:license
> of a graph.

Well... fine with me. But what I am saying is that, from a Semantics point of view, a label behaves pretty much the same way as a term typed rdf:Graph. At least by the level of semantics which is on that page.

> 
>>>> Although... there is still the subgraphing question pending; 
>>> 
>>> I'd call that the partial-vs-complete graph reference question, but,
>>> yes.   This is one of those cases where people are using DWIM semantics,
>> 
>> 'DWIM' ??
> 
> Do What I Mean.    That is, people are just using Trig with some
> semantics in mind and in their code which may not be the same as other
> people's.   But see email sent 5 minutes ago that maybe frames this in
> an okay way.

Will look.

Ivan

> 
>>> so it's painful to switch to standard semantics.
>>> 
>>> For clarity, we might want to use some syntax like this for now, inside
>>> the group:
>>> 
>>> <u> {= <a> <b> <c> }    for complete-graph semantics
>>> 
>>>    read as <u> denotes something which hasGraph <a> <b> <c>.
>>> 
>>> <u> {+ <a> <b> <c> }    for partial-graph semantics.
>>> 
>>>    read as <u> denotes something which hasGraph a graph that includes
>>>    at least the triple <a> <b> <c>
>>> 
>>> (Earlier I suggested using "..." instead of "+", but that gets
>>> confused with metasyntax.  People use "..." all the time in their
>>> examples to mean they're leaving out some details of the example.)
>>> 
>>> (Also, Eric suggesting using +{...}, but putting an equals outside the
>>> braces has a very different implication.)
>>> 
>>> 
>>>> also whether we want to syntactically determine the nature of the default graph.
>>> 
>>> You mean like whether it's the merge of the named graphs or not?
>> 
>> Yes. This came up reading Tom Baker's examples. The semantics being as it is, whether the default graph is the union of all the graphs or not makes a major difference.
> 
> Maybe in Trig, if there is no default graph, it's the merge.    If you
> want an empty default graph, you have to say "{}".
> 
>    -- Sandro
> 
>> Ivan
>> 
>>> 
>>>    -- Sandro
>>> 
>>>> Ivan
>>>> 
>>>>> 
>>>>> That's it for now...
>>>>> 
>>>>> -- Sandro
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> ----
>>>> Ivan Herman, W3C Semantic Web Activity Lead
>>>> Home: http://www.w3.org/People/Ivan/
>>>> mobile: +31-641044153
>>>> FOAF: http://www.ivan-herman.net/foaf.rdf
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>> ----
>> Ivan Herman, W3C Semantic Web Activity Lead
>> Home: http://www.w3.org/People/Ivan/
>> mobile: +31-641044153
>> FOAF: http://www.ivan-herman.net/foaf.rdf
>> 
>> 
>> 
>> 
>> 
> 
> 
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
FOAF: http://www.ivan-herman.net/foaf.rdf