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

On Sep 6, 2013, at 11:41 AM, Jeremy J Carroll wrote:

> 
> I remain unhappy with this resolution.

You are not alone :-)

> 
> I am reviewing the minutes:
> https://www.w3.org/2013/meeting/rdf-wg/2013-08-21#semantics_and_concepts
> and Peter is correct in saying:
> "Jeremy wants there to be a way to require graph names denoting graphs"
> 
> I currently have a quad store with several named graphs, and some of these named graphs 'belong' to 'organizations' within my knowledge model.
> One of the graphs is named <http://my.graph.name.example.org/>,

This seems to be the key point. You have this IRI, and you say it denotes a graph. But how is this fact - that this IRI denotes that graph - made visible in any formal semantics?  What specification of what standard gives you a way to impose a fixed interpretation on an IRI? AFAIK, there is no such standard. 

SPARQL 1.1 says (8. "RDF Datasets") " ... each named graph is identified by an IRI."  It does not say that the IRI denotes the graph. It does not say that an interpretation I of the dataset (if it defined such a thing, which it does not) is required to satisfy I(<nameIRI>) = <the graph that it names>. The SPARQL specifications completely fail to provide a precise semantics. And the result, as one might expect. is a vague muddle at exactly the critical semantic point. (There is some history behind this, but it probably should not be discussed in a public email.)

You will not find anything in the entire SPARQL specification which guarantees that the name of a named graph refers to or denotes the graph. RDF 1.1 follows what has now become a settled convention, that the graph-naming relationship displayed in an RDF dataset is simply a local "association", with no semantic weight. The naming IRI might refer to the graph or it might not, so in order for this reference to be relied upon, some other convention or rule has to be appealed to. Unfortunately, as far as I know, no current W3C Recommendation provides such a convention or rule. 

> one of the organizations is syapse:stoogesInc.
> 
> I wish to be able to add a triple:
> 
>   <http://my.graph.name.example.org/> syapse:belongs syapse:stoogesInc .
> 
> to a graph and have that triple mean, according to the RDF Semantics, RDF Concepts and RDF Vocabulary recommendations, that in an interpretation in which the triple is true that:
>   ( I(<http://my.graph.name.example.org/>), I(syapse:stoogesInc) ) is in IEXT(I(syapse:belongs))

Oh sure, it means that alright. The question though is, whether  I(<http://my.graph.name.example.org/>) = the graph you want it to mean. The problem is that there are people who want to use an IRI to simultaneously denote a person (say) but also be the name of a graph (eg of information about that person). And they have deployed systems and much money vested in being able to do this. 

> and for it to not merely be an application convention that we are in fact referring to the named graph in the dataset as the subject of the triple, but for there to be some normative manner, whether formally or informally, that licenses application specific behavior involving the named graph on the basis of the truth of this triple involving the graph name.

I wish. Our discussions in the WG on this topic began with my simply assuming (I took it to be obvious) that names of named graphs denote the graphs they name. It is difficult to adequately describe the strength of the resistance that this produced. I tried pointing out that the paper you and I helped co-author, which introduced the very idea and terminology of "named graph", quite explicitly gave named graphs this obvious semantics, and was told (repeatedly, and strongly) that this reference was not normative, the paper itself was now merely of historical interest, the meaning of the terminology "named graph" had advanced with advances in the field, and that the SPARQL document itself was the only possible normative source for the term "named graph". The SPARQL specifications do not even refer informatively to our paper, you may have noticed. Clearly, appeals to such matters as academic priority have no weight in such a debate. When I dug in my semantic heels, the response was that it would be better to rewrite the RDF semantics rather than allow this 'naming' rule to stand, and indeed several such suggestions for emasculating the RDF model theory were made, and can be found in the WG Wiki.

> Essentially, the promise from RDF is the ability to "say anything about anything".
> Here I seem unable to say anything at all about an RDF graph - I cannot name it in a way in which I can use the name in further RDF.

The basic fault is not RDF's here. As I pointed out at the first WWW conference I attended (Cambridge 1995), the Web provides no way to attach a referent to an IRI: it has no baptism or naming conventions. That was true in 1995 and it is still true in 2013. The usage of "identifies" rather than "denotes" or "refers to" throughout the TAG writings and many W3C specification documents only confuses this further, as many readers assume that this word does imply semantic reference, while others have a different reading or no precise semantic meaning for it at all. 

> Of course, there are some formal limitations such as Russell Paradox, or the Patel-Schneider paradox that constrain the bumper sticker, but the ability to make simple statements about RDF graphs does seem to be a pretty minimalist requirement.
> 
> It does not seem in the spirit of RDF at all to exclude this case, which is of course common practice, because it is often necessary!

RDF 1.1 does not exclude it. It simply observes that other usages are possible, and equally conformant. 

> While, I am sympathetic to the pressures of schedule and the difficulties of finding consensus,
> I do not believe that the WG has delivered the charter requirement of:
> "Standardize a model and semantics for multiple graphs"
> when the current semantics for multiple graphs does not support the ability to make statements about the graphs in the dataset with any normative force.
> 
> An example of informal text that allows me to say something about RDF related concepts is section 1.5 of RDF concepts
> http://www.w3.org/TR/rdf11-concepts/#change-over-time
> 
> This makes it clear that it is reasonable to use the URL associated, by the web architecture, with an RDF source within descriptions of that source in RDF graphs.

It is *reasonable* to do so. But it is also possible, and some think reasonable, to use a different, incompatible, naming convention. So RDF 1.1 punts on the issue, as it must (especially given its very limited charter, which prohibits anything as drastic as, say, a context mechanism to be added to RDF semantics.)

> I wish to have a similar set of reasonable expectations that, in some settings, I can make statements about RDF graphs within a quad store, as well.

You *can* make such statements. Nothing in the RDF 1.1 spec prohibits this or even discourages it. However, it does not provide any way for you to convey this intention to other readers of your quad store, if you publish it openly as an RDF dataset. If I am given a dataset, there is no W3C document that I can use to determine whether or not the names of the named graphs in it refer to the graphs they name. 

Pat

> 
> I believe that this issue is an important one and should not be hived off into an informative WG Note.
> 
> Jeremy
> 
> 
> 
> 
> 
> On Aug 21, 2013, at 10:11 AM, Sandro Hawke <sandro@w3.org> wrote:
> 
>> Jeremy,
>> 
>> Thank you very much for you comments and interest.  As you may know, the Working Group has discussed the issues around Named Graphs and Datasets extensively, for over two years now.  The Last Call version of RDF 1.1 Concepts includes a minimalist design that we believe is a reasonable foundation on which interoperable systems can be built, although in many cases those systems will require additional standards in order to have interoperability. Many designs were considered for adding more expressivity/functionality, but the Working Group decided that none of them were sufficiently mature to include in the current Recommendation-Track documents, which are to be completed by the end of the year.
>> 
>> We have agreed in principle to published two Working Groups Notes to provide some guidance and tools for people to move forward with this minimal design, gathering experience with built on it, to support future standards work.  Specifically, I am drafting one, aimed at programmers using datasets for several common use cases, building on classes like your suggested rdfs:Graph.  Meanwhile, Antoine Zimmerman is drafting another, offering a framework for providing formal semantics to datasets.  As Working Group Notes, as you know, these documents can offer experimental solutions, not refined and tested to the degree required of Recommendations.   If you are interested in reviewing early drafts of the note I'm working on, or otherwise helping (test cases?), please let me know and I'll keep you in the loop.
>> 
>> We understand this isn't your preferred outcome, but under the circumstances, are you satisfied with this response?
>> 
>> Also: please note that the SPARQL Working Group (the successor to DAWG) has concluded.   Its comments list (which you CC'd and I'm also CC'ing) is being used for errata handling and gathering material for a possible future group.    For discussion, the right forums are probably either public-sparql-dev@w3.org or the RDF Working Group.
>> 
>> On behalf of the RDF Working Group,
>>   -- Sandro
>> 
>> 
>> 
>> 
>> 
>> On 07/11/2013 03: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.
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
> 
> 
> 

------------------------------------------------------------
IHMC                                     (850)434 8903 home
40 South Alcaniz St.            (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile (preferred)
phayes@ihmc.us       http://www.ihmc.us/users/phayes

Received on Monday, 9 September 2013 06:52:20 UTC