Re: [Graphs] Proposal: RDF Datasets

Yves,

To answer your concern about readability: indeed, such embedding of RDF
serialization as a literal is not ideal in Turtle of RDF/XML (not to
mention N-Triples...). This is where alternate syntaxes such as Trig or
N3 can prove useful. But the important point is to show that we can keep
the *abstract* syntax as is.


To answer your concern about modifying the parser behaviour: if we are
strictly considering parsing, there is absolutely nothing new parsers
must do. What *may* need to be changed are inference engines. For
example, given:

  <my-graph> rdf:xml-serialization "[str1]", "[str2]" .

an inference engine might want to check whether [str1] and [str2] are
valid RDF/XML serialization, and if they indeed encode the same graph --
else the statements above would be inconsistent. But this does not have
to be *requited*, see below.


To answer your concern about supported formats: we already have that
problem with datatypes: depending on your inference capabilities, you
may or may not be able to detect that "foo"^^xsd:int makes no sense.
Rdf-mt already defines several "levels" of entailments;
"serialization-entailment" could be defined that way.


To answer your question about "scoping" of declaration: as the proposal
is at the abstract syntax level (sorry if that was not clear enough on
the wiki), there can be no syntactical "communication" between the
embedding and the embedded graph; the value of rdf:*-serialization has
to be self-sufficient (and not require any off-band context, such as an
implicit base URI).

  pa



On 08/22/2011 05:36 PM, Yves Raimond wrote:
> Hello!
> 
>> As I promissed to Richard during the last TC, I'm reactivating the
>> thread on his proposal to "lift" the definition of RDF datasets into
>> from SPARQL to RDF concepts [1]
>>
>> My main concern with this proposal is that it defines a somewhat complex
>> structure (the dataset) as a primitive concept in RDF. My gut feeling is
>> that we could instead define more basic concepts, on top of which SPARQL
>> datasets, SPARQL graph stores, and possibly other structures, could be
>> defined. In my understanding, this is what the g-* terminology was
>> aiming at.
>>
>> In this perspective, back in June, I made an alternate proposal [2] for
>> which I got almost no feedback. In a nutshell, it provides a minimal
>> vocabulary for reifying RDF graphs into standard RDF, and sketches the
>> semantics of such a reification. From there, it illustrates how
>> multi-graphs syntaxes (such as Trig) and models (such as SPARQL
>> datasets) can be defined on top of it.
>>
> 
> One concern I have with that proposal is that instructions modifying the parsing behavior are embedded within certain URIs (rdf:xml-serialization). Does that mean, when writing an RDF parser, you'd need to manually check for those specific predicates (which would need to be added as soon as there's a new serialisation for RDF ; rdf:jsonld-serialization, rdf:binaryrdf-serialization, rdf:ntriples-utf8-serialization...).
> 
> Also, the relationship between the holding graphs and the contained graphs would need to be specified exactly - are the prefixes and the base URI shared?
> 
> On a different note, it might be very difficult to read if you have a graph g quoting a graph g2 quoting a graph g3?
> 
> Best,
> y
> 
>> I know that Richard was concerned about several multi-graph models had
>> slight differences (e.g. can a BNode be used as a graph name), and his
>> solution was to endorse one of them and wait for the others to converge.
>> My proposal is rather to provide the building blocks for everyone to
>> describe their model in RDF itself, and leave it open for different
>> models to coexist, which is ok as long as they can all be expressed in
>> plain RDF.
>>
>>   pa
>>
>>
>> [1] http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/RDF-Datasets-Proposal
>> [2] http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/RDF-Quadless-Proposal
>>
>

Received on Monday, 22 August 2011 16:47:45 UTC