Re: proposed second reply to Jeremy's comment about named graphs

On 09/11/2013 10:41 PM, Sandro Hawke wrote:
> On 09/11/2013 08:43 PM, Pat Hayes wrote:
>> I like this. Is it a good idea to also refer to the notes that Sandro 
>> and Pierre-Antoine are supposed to be writing? Just to show we havnt 
>> stopped worrying about it, you understand.
>
> There's seems to be some lack of community memory on this.  I already 
> gave Jeremy the formal reply to Jeremy's rdf:Graph comment, in which I 
> explained about those two notes, etc [1].   He said he still wasn't 
> happy [2].    I asked for more details [3], and he gave test cases [4] 
> and proposed text [5].   I think we need to respond to *those* not to 
> his earlier comments.
>
> [1] 
> http://lists.w3.org/Archives/Public/public-rdf-comments/2013Aug/0050.html
> [2] 
> http://lists.w3.org/Archives/Public/public-rdf-comments/2013Sep/0005.html
> [3] 
> http://lists.w3.org/Archives/Public/public-rdf-comments/2013Sep/0007.html
> [4] 
> http://lists.w3.org/Archives/Public/public-rdf-comments/2013Sep/0010.html
> [5] 
> http://lists.w3.org/Archives/Public/public-rdf-comments/2013Sep/0017.html
>
> I haven't yet had a chance to read and think about [4] and [5].
>

Okay, I looked at them.    I don't see how one can accept both his 
proposed definition of rdf:Graph and his proposed outcome of TC1 (in 
[4]).    I think he's proposing that when rdf:Graph is used, the graph 
name denotes the graph, but surely in that case the TC1 entailment must 
hold -- and he doesn't want it to -- because his mental model is really 
gboxes.

I guess I'll ask him.

         - s

>        -- Sandro
>
>
>
>> Pat
>>
>> On Sep 11, 2013, at 1:28 PM, Peter Patel-Schneider wrote:
>>
>>> Dear Jeremy:
>>>
>>> This is a second official response to your comment about named 
>>> graphs in
>>> http://lists.w3.org/Archives/Public/public-rdf-comments/2013Jul/0021.html 
>>> and
>>> http://lists.w3.org/Archives/Public/public-rdf-comments/2013Sep/0005.html 
>>>
>>>
>>>
>>> The RDF Working Group believes that there are several ways in which RDF
>>> graphs and datasets are and will be used.  These include ways that 
>>> fit into
>>> your use cases, where the graph names denote the graph they name or 
>>> some
>>> other formal graph-related construct and where you would indeed say
>>> something like
>>>
>>> jjc:graph {
>>>    jjc:graph dc:creator "Jeremy J. Carroll" .
>>> }
>>>
>>> However, there are also ways that do not fit into your use cases, for
>>> example where the graph names are IRIs that denote some other 
>>> entity, such
>>> as
>>>
>>> jjc:jjc {
>>>    jjc:jjc rdf:type foaf:Person .
>>>    jjc:jjc foaf:lastName "Carroll" .
>>>    jjc:jjc foaf:knows jjc:pfps .
>>> }
>>>
>>> If the RDF semantics required that all graph names denote graph-related
>>> constructs this would interfere with these other use cases. 
>>> Therefore the RDF
>>> Working Group decided to not so require.
>>>
>>> Further the RDF Working Group was unable to agree on even a weak 
>>> theory of
>>> named RDF graphs, such as one conditioned on explicit typing. Even the
>>> nature of what graph names might denote was problematic: does the 
>>> name of an
>>> RDF graph denote the graph itself, does it denote some other 
>>> construct that
>>> is related to the graph, or does it even denote the semantic meaning 
>>> of the
>>> graph?
>>>
>>> Therefore the working group has produced a very minimal 
>>> specification for
>>> RDF datasets and named graphs that does not depend on denotation.
>>>
>>> This approach produces maximally compatability, but does not produce
>>> inferences that might be desirable in some use cases.  If you do want
>>> certain inferences to be part of your approach, such as the first 
>>> example
>>> above entailing
>>>    jjc:graph rdf:type jjc:Graph.
>>> you can define and implement a particular RDF entailment regime that
>>> sanctions these inferences.
>>>
>>> The RDF Working Group believes that this minimal approach will allow
>>> different approaches to named graphs to coexist some allowing what 
>>> you want
>>> and others incompatible with what you want.  The flourishing 
>>> approaches can
>>> then be considered for standardization at a later time.
>>>
>>>
>> ------------------------------------------------------------
>> IHMC                                     (850)434 8903 home
>> 40 South Alcaniz St.            (850)202 4416   office
>> Pensacola                            (850)202 4440   fax
>> FL 32502                              (850)291 0667   mobile (preferred)
>> phayes@ihmc.us       http://www.ihmc.us/users/phayes
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>

Received on Thursday, 12 September 2013 03:00:56 UTC