- From: Jeremy J Carroll <jjc@syapse.com>
- Date: Fri, 19 Jul 2013 09:35:41 -0700
- To: "public-rdf-comments@w3.org Comments" <public-rdf-comments@w3.org>
- Message-Id: <CAE0EEDC-5963-4FE6-AFA0-096CE154C2AD@syapse.com>
A brief update on where I am at, after informal discussion.
1) I find Pat's comment:
http://lists.w3.org/Archives/Public/public-rdf-comments/2013Jul/0031
fairly compelling.
In particular
[In the other reading] " a dataset expresses trinary rather than binary predications"
is consistent with RDF 1.0, and different from my preferred point of view, articulated in Carroll, Bizer, Hayes and Stickler, 2004.
This gives substance to Sandro's claim "so nothing we could pick wouldn't cause someone problems."
2) Here is a concrete proposal to address "I would like to use rdf to describe graphs in a dataset," that I hope respects Pat's observation, and is somewhat more straightforward than the out-of-band indicator of semantic intent that Sandro was suggesting.
Modify RDF Schema to include new class rdfs:Graph
[[[
rdfs:Graph
rdfs:Graph is the class of graphs. All instances of rdfs:Graph correspond to the RDF model of a graph described in the RDF Concepts specification [RDF-CONCEPTS].
An instance of rdfs:Graph MAY also be described in an RDF dataset, in which case the triples in the graph SHOULD/MUST be the triples as specified in the dataset.
]]]
(I would be happy with either SHOULD or MUST)
The key here is the MAY. People not wanting this semantics for the dataset can simply omit the
<uuu> rdf:type rdfs:Graph
triple. There is no implication from the dataset
GRAPH _:a { <s> <p> <o> }
GRAPH _:b { <s> <p> <o> }
to
_:a rdf:type rdfs:Graph
(And following the style of RDF Semantics, this non-implication could be called out)
But, if (_:a rdf:type rdfs:Graph) and (_:b rdf:type refs:Graph) are known by being specified elsewhere (with application specific definition of "known", following Carroll et al. 2004), then _:a does indeed consist of a single triple, as does _:b and those two triples are the same; and we can have different metadata describing _:a and _:b ….
i.e. I am quite happy with an intensional rather than an extensional definition of rdfs:Graph so that
GRAPH _:a { <s> <p> <o> }
GRAPH _:b { <s> <p> <o> }
_:a rdf:type rdfs:Graph
_:b rdf:type rdfs:Graph
_:a <pp> <oo>
does not imply
_:b <pp> <oo>
(Again this non-implication would be worth calling out in RDF Semantics)
(just like knowing that two classes have the same members does not imply that they are identical concepts, i.e.
<a> rdfs:subClassOf <b>
<b> rdfs:subClassOf <a>
<a> <p> <o>
does not imply
<b> <p> <o>
)
It seemed that at least one of Sandro's alternative's points of view wanted this, and while I wouldn't much mind someone who did that in the privacy of their own application, it would be too challenging to be RECOMMENDED.
Jeremy J Carroll
Principal Architect
Syapse, Inc.
On Jul 11, 2013, at 12:06 PM, Jeremy J Carroll <jjc@syapse.com> wrote:
>
>
> Hello
>
> This is a formal comment on http://www.w3.org/TR/rdf11-concepts/#section-dataset, and it appears a comment on
> https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-schema/index.html
> and quite possibly on the RDF Semantics ….
>
> It seems to be a suggestion to reopen issue 35
> http://www.w3.org/2011/rdf-wg/track/issues/35
> which points to
> http://www.w3.org/TR/sparql11-service-description/
> hence I am CC-ing dawg.
> The last part of this message discusses problems in using service description to meet my use case: to me, this is not a comment on DAWG's work, but a comment that RDF Core cannot use DAWG's work of more limited scope to duck the issue.
>
>
> Summary: I would like to use rdf to describe graphs in a dataset, e.g. to say who the author was.
>
> as a simple example
>
> my:graph {
> my:graph dc:creator "Jeremy J. Carroll" .
> }
>
> I cannot see how to do this with the current drafts, editors drafts, etc.
>
> A possible approach would be to reopen issue 35 and have a class rdfs:Graph, s.t. for a <URI> used as the name of a graph in a dataset the triple
> <URI> rdf:type rdfs:Graph
> holds.
> More weakly, I would be satisfied with such a concept being added to the RDF vocabulary, without the implication above holding, but a suggested usage pattern.
>
> Also, I basically finished this message before finding issue 35 and it's superficially reasonable resolution that sd:Graph may meet my needs. This suggests that some documentation link from either RDF Concepts or RDF Schema or RDF Semantics to SPARQL Service Description would be helpful ….
> However, the Service Description doc
> http://www.w3.org/TR/sparql11-service-description/
> ducks on the issue of whether the name denotes the graph, and so does not give me a clear place to put such metadata.
> I think if the RDF WG tried writing such documentation, they would discover that the resolution of issue 35 would unravel - the trick is to allow such unravelling without having too much of the named graphs work unravel.
>
> ----
>
>
> Here is my actual use case …..
>
>
>
>
>
> I first give my motivation, then I give my weak suggestion.
>
> Motivation:
> =========
>
> I referred to RDF Concepts 1.1 today because I am constructing an RDF dataset and wished to add metadata concerning the named graphs.
> I am trying to articulate a multi tenant architecture over a SPARQL end point, in which each user is assigned to a specific organization, and then depending on this organization, they have access to different named graphs.
>
> I wish to refer to the named graphs using the URI names I have assigned to them, and I wish to create my own property to add this metadata
>
>
> Concretely, my property might be
> syapse:owningOrganization
>
> and the quads I was thinking of producing include
>
> GRAPH <https://test.syapse.com/graph/syapse> {
> <https://test.syapse.com/graph/syapse> syapse:owningOrganization syapse: .
> syapse:owningOrganization rdf:type owl:FunctionalProperty .
> syapse:owningOrganization rdfs:range syapse:Organization .
> syapse: rdf:type syapse:Organization .
> syapse:Organization rdf:type rdfs:Class .
> …
> …
> }
>
> GRAPH <https://test.syapse.com/graph/ontology/base> {
> <https://test.syapse.com/graph/ontology/base> syapse:owningOrganization syapse: .
> …
> …
> }
>
> GRAPH <https://test.syapse.com/graph/ontology/sys> {
> <https://test.syapse.com/graph/ontology/sys> syapse:owningOrganization syapse: .
> …
> …
> }
>
> GRAPH <https://test.syapse.com/graph/ontology/c2> {
> <https://test.syapse.com/graph/ontology/c2> syapse:owningOrganization <https://test.syapse.com/graph/southParkUniversity> .
> …
> …
> }
>
> GRAPH <https://test.syapse.com/graph/southParkUniversity/abox> {
> <https://test.syapse.com/graph/southParkUniversity/abox> syapse:owningOrganization <https://test.syapse.com/graph/southParkUniversity> .
> <https://test.syapse.com/graph/southParkUniversity> rdf:type syapse:Organization .
> …
> …
> }
>
>
> This allows me to run a privileged SPARQL query across the whole dataset to find out which graphs are assigned to which organization, and then knowing which organization a user is in, I can have application logic to determine which named graphs they can access, and restrict their queries to those named graphs.
>
>
> Weak suggestion
> ==============
>
> I read the very limited text in the dataset section, and the note as reflecting a victory for those who do not want the implication that the name of the graph is a graph to hold.
> As a long standing advocate of the other position in which, of course, it denotes … I am somewhat disappointed.
>
> However, adding such a vocab item can allow the users to decide on a case-by-case basis whether such denotation is intended or not.
>
> e.g.
>
> rdfs:Graph
> rdfs:Graph is the class of RDF Graphs as defined by RDF Concepts.
>
>
> Semantics:
>
> <g> { …. }
>
> does not imply
>
> g rdf:type rdfs:Graph
>
>
> but
>
> <g> { …. } .
> <g> rdf:type rdfs:Graph
>
> does imply that the interpretation of <g> is given by the graph.
>
>
> Problems with the Service Description approach
> =====================================
>
> Reading
> http://www.w3.org/TR/sparql11-service-description/
> my understanding is that the intent is for the endpoint to provide (closed) metadata about the dataset, which does not enable further comment even from someone with update privileges on the dataset.
>
> e.g. in
>
>
>
> @prefix sd: <http://www.w3.org/ns/sparql-service-description#> .
> @prefix ent: <http://www.w3.org/ns/entailment/> .
> @prefix prof: <http://www.w3.org/ns/owl-profile/> .
> @prefix void: <http://rdfs.org/ns/void#> .
>
> [] a sd:Service ;
> sd:endpoint <http://www.example/sparql/> ;
> sd:supportedLanguage sd:SPARQL11Query ;
> sd:resultFormat <http://www.w3.org/ns/formats/RDF_XML>, <http://www.w3.org/ns/formats/Turtle> ;
> sd:extensionFunction <http://example.org/Distance> ;
> sd:feature sd:DereferencesURIs ;
> sd:defaultEntailmentRegime ent:RDFS ;
> sd:defaultDataset [
> a sd:Dataset ;
> sd:defaultGraph [
> a sd:Graph ;
> void:triples 100
> ] ;
> sd:namedGraph [
> a sd:NamedGraph ;
> sd:name <http://www.example/named-graph> ;
> sd:entailmentRegime ent:OWL-RDF-Based ;
> sd:supportedEntailmentProfile prof:RL ;
> sd:graph [
> a sd:Graph ;
> void:triples 2000
> ]
> ]
> ] .
>
> <http://example.org/Distance> a sd:Function .
>
>
> The description of the named graph is attached to an explicitly blank node, that I then cannot make further comment in in my own graph or indeed inside the graph named <http://www.example/named-graph> itself.
> Thus I cannot add a dc:creator (or syapse:owningOrganization) triple inside this service description (because SPARQL 1.1 does not give me, nor does it intend to give me) write access to the service description, even if I have write access to <http://www.example/named-graph>
>
> These issues perhaps could be addressed by making sd:graph and sd:name both 1-1 properties …. but I imagine there may be some reluctance ….
>
> NB - this last comment, is not a formal comment on the Service Description Spec, which seems fit-for-purpose, it is a comment on the current resolution of Issue-35 which neglects that the purpose of SPARQL Service Description is less than is needed to address the issue
>
>
>
>
>
>
> Jeremy J Carroll
> Principal Architect
> Syapse, Inc.
>
>
>
Received on Friday, 19 July 2013 16:36:12 UTC