W3C home > Mailing lists > Public > public-rdf-wg@w3.org > April 2011

Re: Graphs, some quick comments

From: Nathan <nathan@webr3.org>
Date: Fri, 22 Apr 2011 01:02:58 +0100
Message-ID: <4DB0C5B2.4020707@webr3.org>
To: Pat Hayes <phayes@ihmc.us>
CC: RDF WG <public-rdf-wg@w3.org>
Pat Hayes wrote:
> On Apr 21, 2011, at 10:52 AM, Nathan wrote:
>> (just dropped these in #swig, copying here)
>> RDF is defined/constrained by it's serializations currently, so anything in the model/abstract is in the serializations, so when we discuss things like multiple graphs, graph literals, named graphs, it's done in terms of syntax, when really there is hardly ever a case where you need multiple graphs in the syntax, other than when dumping stores or sets of data, and that ain't RDF.
>> however, behind the interface you need this stuff all the time, but not over the wire, and RDF doesn't handle that.
>> so, perhaps a higher problem is: RDF is defined in terms of on the wire needs, but RDF is used as a data model for working with data behind the interface, and the two have different requirements.
> I guess I have always been under the impression that the entire RDF standard is intended to define how RDF is used 'on the wire'; that is, as a notation for transmitting data on the Web. Applications - even quite large applications, such as a thousand linked servers on an intranet, say - are perfectly free to take RDF and do absolutely anything to it. They can make it into quads or put literals into subject position or invent their own identifiers or replace bnodes with URIs or even make spaghetti bolognaise out of it, and none of that violates the RDF specs, provided it is all done behind the public interface. It is not our job, as a WG, to make rules about what people are allowed to do inside their own software systems with the curtains drawn. We only specify how the public face of RDF is supposed to look and be interpreted; and we only even do that in order to try to improve the chances of people at different times and places writing RDF tools that will interoperate suc
cessfully when one of them consumes some RDF that was produced originally by the other.  

See I was always under the impression that the RDF standard was /used/ 
to both define a notation for transmitting data on the Web and as a 
general triple based data model, and that both libraries and other 
specifications often had a more general notion of these triples, that 
isn't defined anywhere, and that afaict, the RDF concepts and semantics 
could handle, even if it kept the syntactic limitations.

> So why are we even having this discussion? 

As above, and specifically because:

- the topic comes up very often on various lists in various contexts and 
it seems like a constant source of confusion for many, and that some may 
be looking for this WG to provide at least some infos / guidance / form 
of reference.

- many of the use cases on the wiki under different TFs are around 
behind the interface usage of RDF data, often with a more generic model 
(especially to do with multiple graphs, provenance, digital signing 
etc), and to me at least this shows that these general use cases that 
aren't required to be in the syntax or transported over the wire are 
coming to the fore and people want to know what to do (in a standardized 

- personally when working on the RDF API these syntactic restrictions 
really risk making it in to the API as also defining the constrains for 
various interfaces (like RDFTriple) and that would limit the 
functionality of any implementations of those interfaces. But how can 
the RDF API be out of sync with RDF, or speak of undocumented things 
with no source of reference? Conversely, if we do allow these 
generalized triples with none of the syntactic constraints of RDF, then 
we have a possible introduction of unexpected functionality since the 
graphs potentially can't be serialized in the official RDF 
serializations. Seems like a no win, and for me is part of the reason 
why the topic keeps coming up, over and over again.

The big three, each with different uses, are well known, literal 
subjects, blank node predicates, and increasingly some form of quoted 
graphs as use cases for them appear.

So I guess the point is, that people and apps do all these other things 
you mention above (other than perhaps making spaghetti bolognaise out of 
it), but whenever they do, they:

a) have no guidance or reference
b) immediately make it "not RDF" (so what is it then?)
c) feel like they mustn't, shouldn't, can't
d) struggle to interoperate, even behind the web interface

.. and for what good reason?

'tis why I'm raising this again anyway.



> Pat
>> if you look at the RDF Graph usecases on the wiki, you'll notice that most of them are about managing or working with data, and people are using the syntax of trig or quads to say what they mean - but only the dumping stores cases actually /require/ having anything in the serialization.
>> Best,
>> Nathan
> ------------------------------------------------------------
> IHMC                                     (850)434 8903 or (650)494 3973   
> 40 South Alcaniz St.           (850)202 4416   office
> Pensacola                            (850)202 4440   fax
> FL 32502                              (850)291 0667   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
Received on Friday, 22 April 2011 00:04:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:58 UTC