- From: Sandro Hawke <sandro@w3.org>
- Date: Mon, 14 Oct 2013 16:37:26 -0400
- To: Jeremy J Carroll <jjc@syapse.com>,www-archive@w3.org
Jeremy J Carroll <jjc@syapse.com> wrote: > >Hi Peter > >thank you and the WG for the time spent considering my issue. > >I am sorry that you have failed to reach a satisfactory response, and >understand the difficulties involved. > >My current intent is to raise a formal objection for consideration by >the director during the transition review. > >I will be clear in that objection that I do not agree with Sandro > >http://lists.w3.org/Archives/Public/public-rdf-wg/2013Oct/0075.html > >that I am in a Solomon and the Baby situation, and that I do not >believe it is best that the specification dies; however, I do believe >that asking the director to consider whether asking the WG to actually >resolve this issue is appropriate. > What other option do you see? The charter expires in about 10 weeks now. If we're not at PR then, I think the spec dies.... - Sandro >I will be drafting the objection in the next 2 weeks: if the WG would >like me to accelerate that process please let me know. > >Jeremy J Carroll >Principal Architect >Syapse, Inc. > > > >On Oct 11, 2013, at 1:03 PM, Peter F. Patel-Schneider ><pfpschneider@gmail.com> wrote: > >> Dear Jeremy: >> >> This is a second official response to your message about rdfs:Graph >and >> RDF datasets, >> >http://lists.w3.org/Archives/Public/public-rdf-comments/2013Jul/0021.html, >> which is being tracked as ISSUE-142. >> >> The first official response from the working group was >> >http://lists.w3.org/Archives/Public/public-rdf-comments/2013Aug/0050.html >> which stated that the working group was unable to agree on any >proposal >> for RDF datasets that goes beyond the very minimal proposal in its >current >> documents. You responded, in >> >http://lists.w3.org/Archives/Public/public-rdf-comments/2013Sep/0005.html, >> that you were not satisfied with this situation. >> >> The working group again discussed RDF datasets and was again unable >to come >> up with any viable solution. The only resolution that was acceptable >was a >> negative one - the RDF working group will leave further semantics of >> datasets and named graphs to some future working group. Hopefully at >that >> time there will be one or more communities of practice using aspects >of RDF >> datasets and named graphs that can be used as the starting point for >> portions of a W3C recommendation. >> >> The working group realizes that the current situation is not totally >> satisfactory to you, but the working group has expended a lot of >effort on >> this topic already and has been unsuccessful. There are no >forseeable >> possibilities of a breakthrough here and thus the working group will >be >> concentrating its efforts in other areas so as to finish the work it >needs >> to do. >> >> Please indicate whether you wish to pursue this issue further, or >whether >> leaving the situation unchanged in this area is acceptable to you. >Thank >> you for your concerns on this topic. >> >> Yours sincerely, >> Peter F. Patel-Schneider >> for the RDF Working Group >> >> >> >> On 07/11/2013 12:06 PM, Jeremy J Carroll 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. >>> >>> >>> >>> >> -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Received on Monday, 14 October 2013 20:37:22 UTC