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 <san...@w3.org
<mailto:san...@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