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

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