Re: (proposal) was Re: defn of Named Graph

Hi all,

I like this idea of a note.

And, to reassure Peter, in my understanding it does define a new entailment
regime, as it constrains the interpretations of datasets more than what
standard RDF semantics does. Not sure how to formally express this,
though...

  pa


On Thu, Sep 26, 2013 at 10:29 PM, Peter Patel-Schneider <
pfpschneider@gmail.com> wrote:

>   Hmm.
>
>  Well putting something like this in a Note should have less changed of
> causing damage, I guess.
>
>  But then I think that there should be some distance between any proposal
> in any such note and the core of RDF.  I think that this distance can come
> from defining a new entailment regime, perhaps called something like the
> denoting-but-nothing-else-graph-name entailment regime.  However, there is
> still no definition of how this entailment regime is supposed to work.
>
> peter
>
>
>
> On Thu, Sep 26, 2013 at 12:02 PM, Sandro Hawke <sandro@w3.org> wrote:
>
>>  On 09/26/2013 02:18 PM, Peter Patel-Schneider wrote:
>>
>>
>>
>>
>> On Thu, Sep 26, 2013 at 10:32 AM, Sandro Hawke <sandro@w3.org> wrote:
>>
>>>  On 09/26/2013 12:00 PM, Peter Patel-Schneider wrote:
>>>
>>>  Umm,  doesn't a lot of this have normative consequences?   If not,
>>> then is there any reason to have it?  If so, then both Concepts and
>>> Semantics will have to have changes to support it, and there has to be a
>>> design that the WG can vote on before proceeding.
>>>
>>>
>>>  There's a conceptual part (that doesn't affect running code) and an
>>> optional part that would just be in a WG Note.
>>>
>>> The conceptual part is (1) telling people what a "Named Graph" is, and
>>> maybe (2) shifting the terminology around "RDF Graph".    My sense is this
>>> would clear up a lot of confusion, but perhaps I'm just arguing about
>>> angels on the head of a pin and this would cause more confusion.  I have no
>>> interest in pushing this if people are okay with the status quo.   We claim
>>> RDF Graphs are mathematical sets, but that doesn't seem to be how the real
>>> world works with them.   Does that matter?    *shrug*
>>>
>>> The optional part is one RDF class, with a standard name (eg
>>> rdf:NGDataset), which would allow people to indicate in a dataset that it
>>> has certain semantics (that seem obvious to me, and I think most people use
>>> without it being formally specified).   I also have no interest in pushing
>>> this, if no one needs that kind of interoperability.
>>>
>>
>>  How does this optional-but-normative semantics get specified?   I would
>> think that it would require wording in both Concepts and Semantics, not in
>> a WG note.
>>
>>
>>  We have two levels of specs, right?  There are the ones that are
>> thoroughly reviewed and proven to be implentable, which we call
>> Recommendations.  And other ones that we still think are useful, but not
>> particularly reviewed or tested, which we can publish as Notes.   Remember
>> LBase?
>>
>> Notes with normative content are a step up from W3C Submission, two steps
>> up from a self-published spec, and three steps up from a blog post, but a
>> big step down from a Recommendation.
>>
>> In terms of normativity, my understanding is it would only need to be in
>> Concepts or Semantics, or normatively referred to from them, if
>> implementing it was required in order to be a conformant RDF system
>> (however that's defined in Concepts and Semantics -- that's another
>> question).     And I don't think that's the case here -- we've decided you
>> can have a conformant RDF system, with datasets, that uses only the
>> semantics for Datasets as currently specified in RDF Concepts.
>>
>>       -- Sandro
>>
>>
>>
>>
>>   Or maybe you are proposing that there be an entailment regime for
>> this.  However, if this is the case, then there is no need for the WG to
>> specify the entailment regime, as specifying entailment regimes can be done
>> by anyone.
>>
>>
>>
>>>
>>> If the WG passes on both of these, they can be handled later, except
>>> that it'll be harder to shift the terminology.
>>>
>>>        -- Sandro
>>>
>>>
>>>
>>  peter
>>
>>
>>
>>
>