W3C home > Mailing lists > Public > www-archive@w3.org > September 2013

Re: rdfs:Graph ? comment on http://www.w3.org/TR/rdf11-concepts/#section-dataset and issue 35

From: Sandro Hawke <sandro@w3.org>
Date: Tue, 17 Sep 2013 14:45:59 -0400
Message-ID: <5238A367.1050301@w3.org>
To: Jeremy J Carroll <jjc@syapse.com>
CC: www-archive@w3.org, Pat Hayes <phayes@ihmc.us>
On 09/17/2013 12:35 PM, Jeremy J Carroll wrote:
> Some in line responses ...
>
> On Sep 16, 2013, at 6:37 PM, Sandro Hawke <sandro@w3.org 
> <mailto:sandro@w3.org>> wrote:
>
>> [moved to www-archive and cc Pat for now]
>>
>>
>>> So, we could scrub the idea of having a class, and instead define a 
>>> property.
>>>
>>> An alternative proposed modification, which clarifies my desired NO 
>>> to your entailment
>>>
>>
>> This is a magic property, right?   It's not a normal property in the 
>> RDF semantics, something in the domain of IEXT, because if it were it 
>> would have extensional semantics….
>
> No - the property does have extensional semantics, and so the 
> relationship between the name and the graph becomes intensional 
> related by the "names graph" property.
>
>
>>
>>> [[
>>> 3.7 The rdf:namesGraph property
>>>
>>> This section defines a vocabulary item rdf:namesGraph in addition to 
>>> those in [RDF-SCHEMA].
>>>
>>> rdf:namesGraph is an instance of rdf:Property that is used to state 
>>> that a resource is a name for a graph.
>>>
>>> A triple of the form:
>>>
>>> R rdf:namesGraph G
>>>
>>> states that G is an RDF graph and R is a name for the graph G.
>>
>> In normal RDF semantics, the property has no access to the term R, 
>> just to I(R).    The truth of triple is unchanged if you replace the 
>> subject with a different subject denoting the some thing.    The 
>> truth of :a :b :c is the same as the truth of :a2 :b :c if I(:a) = 
>> I(:a2).
>>
>> But rdf:namesGraph is special -- it somehow reaches around I and IEXT 
>> to get directly at the subject term itself….?
>
> No - this is just a perfectly normal property we are actually talking 
> about ( I( R ) , I(G) ) in IEXT(I(rdf:namesGraph)). The form of the 
> text is copied exactly form RDF Vocabulary: there have not been 
> comments on that document suggesting that the form contradicts the 
> semantics document, so I felt it safe and consistent to stick with 
> that form.
>

Oh, okay.  So, test case:

   :gn1 rdf:namesGraph :g1;
           owl:sameAs :gn2.
   GRAPH :gn1 { :a :b :c }.
entails
   :gn2 rdf:namesGraph :g1;

Yes?

Are there any cardinality constraints?    I think you're saying it's a 
functional property, so

  :gn1 rdf:namesGraph :g1a, :g1b.
  :g1a :p :o.
entails
  :g1b :p :o.


>>
>>> If R is an IRI, and that IRI is used to name a graph in a dataset, 
>>> then within that dataset the resource G SHOULD correspond to the 
>>> named graph.
>>>
>>
>> I don't understand why you keep using SHOULD.    I don't see 
>> semantics as the kind of place for SHOULDs.
>
> I am not suggesting any change to the semantics document.
> I would be quite happy with a MUST, but a SHOULD is fine if other 
> people wish to do things different, or are already doing things different.
>
> I think a MUST is definitely arguable - if you use an IRI twice in the 
> same document (or dataset) then it seems to me to be Web 101 that you 
> are talking about the same thing in the two places.
> However in the formal semantics unless we are wanting to define 
> genuinely magic properties about the math to do with graphs, then we 
> do not need a MUST. (e.g. rdf:isIsomorphicTo, e;g; rdf:tripleCount) 
> are properties that we could choose to define, but it does not really 
> seem to be using RDF for its core mission of describing resources.
>
>>
>>> The rdfs:domain of rdf:namesGraph is rdfs:Resource. No rdfs:range is 
>>> specified.
>>> ]]
>>>
>>>
>>> ===
>>>
>>> With this my particular use case to add metadata about the graph as 
>>> an intensional as opposed to an extensional object would be 
>>> addressed as follows.
>>>
>>>      PREFIX : <http://example.org/#>
>>>      PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
>>>      
>>>      GRAPH :g1 { :g1 rdf:namesGraph _:g ; rdfs:comment "An example graph" }
>>
>>
>>
>> But, but ... in that case you don't need rdf:namesGraph at all.   
>> Since you're not actually using _:g, just put your properties on :gn1 
>> and you're fine.
>
> I am only using rdf:namesGraph to convey the semantic intent that the 
> subject really is a graph name, since the working group resists making 
> that a general rule

It resists making it a general rule, because there's no consensus, when 
you get into the details, what it means.   Everyone is fine with the 
general idea, sure, of course, that's the graph name and that's the 
graph, and (waving hands) in some sense that graph name is naming that 
graph.   But when you try to figure out details like entailments, 
disagreement start to arise that would break interoperability.    We 
don't want to hand out directions to where the party is unless we can 
actually write directions that will get everyone to the same spot.    So 
far, no one's been able to write directions that get even the folks in 
the WG to the same spot.

> (which I see as broken: if you use the same IRI twice in the same 
> document then it seems to me to be Web 101 that you are talking about 
> the same thing in the two places) but still
>

That's settled by the RDF 1.1 specs.    RDF terms used as graph names 
denote exactly the same as they do as RDF terms anywhere else.

What's not clear is the relationship between the thing the graph name 
denotes and the associated graph.    The only thing we're all agreed on 
is that they are associated by the structure of the dataset.

>>
>> Does that not do what you want?   (True there's no semantic 
>> connection to the triples, but why do you need one?   Since you're 
>> not using _:g, I claim that means you don't need the rdf:namesGraph 
>> triple at all.)
>
> I shouldn't need rdf:namesGraph at all - but the working group appears 
> strangely intent on the idea that you can use a URI that identifies a 
> person to name a graph that it does not identify. To me that is perverse:

Agreed.  In fact, the Working Group agrees that is perverse.  The one WG 
member who said they routinely do that in products agreed it was 
perverse, and said he could not / would not object to the WG forbidding it.

That's just a trivial proxy for the more subtle disagreements, like the 
one about whether graph names associated with the same graph co-denote 
(the test case that made you bring up intensionality), and also this one:

Do these two datasets contradict each other:

D1:
    :o owl:sameAs :o2.
    GRAPH :g1 { :s :p :o.}
D2:
    :o owl:sameAs :o2.
    GRAPH :g1 { :s :p :o.   :s :p :o2}

Where the WG can't get consensus is on these kind of test cases.

Also, when we consider graph names might be dereferenceable URLs, people 
disagree quite vehemently about how that relates to datasets.


> because you end up with the same IRI being used for multiple purposes 
> in the same document. It then sabotages my goal, to use the name of 
> the graph to describe the (intent about the) graph
>
> I would be more than happy not to have the property and to have 
> normative text with SHOULD force that says that a graph name 
> identifies the graph.
>

I think you want something like:

GRAPH :group1output { ... }
:group1output g:maintainedBy :group1

and then the system can allow the people in :group1 to alter the triples 
in that graph, and everyone else can see that :group1 is responsible for 
those triples.   Right?

So, with the current specs you can pretty much do that by defining 
g:maintainedBy like this:

      g:maintainedBy: a property relating ____s to the social entities 
responsible for maintaining them.

The only problem is what word goes in the blank.   Whatever it is, it's 
the class of things that :group1output denotes.  The obvious term for 
that is Named Graph.   Or MutableGraph or GraphSlot or G-Box or 
Surface.   But the world seems to call that "Named Graph", which is 
decided NOT a subclass of "RDF Graph" because if it were, then the 
property inferences we don't want would hold.

So.   Maybe the spec should say that?

    RDF Terms appearing as graph names in an RDF Dataset each denote an
    instance of class rdf:NamedGraph.   RDF does not characterize or
    restrict instances of rdf:NamedGraph, and there is no connection
    between a NamedGraph and the RDF Graph which appears paired with it
    in a Dataset beyond the fact that they are paired in that Dataset.

Is that any better for you?    The group might go for that, I suppose.   
Personally, what I'd really like is this:

    RDF Terms appearing as graph names in an RDF Dataset each denote an
    instance of class rdf:NamedGraph.   An RDF Named Graph is therefore
    a sort of "slot" in a dataset, associated with each graph name
    appearing in that dataset.   The RDF Graph paired with a particular
    name in an RDF Dataset conveys exactly the RDF Triples which are in
    the RDF Named Graph denoted by that name.

    Note that RDF Named Graphs are subtly different from RDF Graphs, in
    that the identity of an RDF Graph is entirely determined by the set
    of triples it contains, since it is defined as being that set.  This
    means two RDF Graphs which contain exactly the same triples are, by
    definition, the same graph (and by definition have all the same
    properties, including metadata). In contrast, RDF Named Graphs have
    identity distinct from the triples they contain.

Wow.    I'm really happy with that.....      What do you think?

            -- Sandro
Received on Tuesday, 17 September 2013 18:46:08 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:44:23 UTC