Re: Observations (named graphs, blank node closurs)

>> No matter how starkly and arbitrarely HP likes to state its papers 
>> that "the semantic web is a collection of namable RDF graphs", the 
>> truth is different: there is no consensus on this. I therefore cant 
>> understand such wide support for this construct.
>
>
> The named graph paper you reference has 4 authors with 4 separate 
> affiliations, 2 commercial, 2 academic.
>
Sorry, I was thinking to the earlier HP lab tech reports that's where 
the line was first published.

>> Name graph are *one* way to provide context. and clearly a non 
>> standard one. Others have proposed quadruples, others quituples, why 
>> not supporting them as well?
>
>
> The RDF dataset approach is the one the WG decided on.  Several 
> members of the WG have deployed systems that contrinbuted ideas to the 
> discussuion as well seeing what other things outside the working group 
> had addressed various aspects of this area.
>
> The working draft does not discuss "trust" or "context" (those two 
> words don't appear in the text).
>
> We hope it will enable such solutions to be built.
>
I understand the bare practical aspects "hey we implemented it" but 
please understand mine: i just posted an example which shows how awkward 
NG make situations when more than a concern is addressed at the same time.
I am trying to make a reasoned description why deploying NG (as a 
central feature) might result in a false step for a generic language for 
the SW.  Because they look like context but they only act as such in 
certain applications. In others applications I'd expect it might even be 
a trap or something that leads to infinite hacks to cope with mutating 
requirements.

>>
>> Now.. should sparql specification be flooded with specific syntactic 
>> constructs to support them all? obviously not.
>> But it might be a start to support the only official constructs to 
>> talk about triples and that is.. reification, which is not even 
>> mentioned in the current draft.
>
>
> There is nothing in the current draft about reification because it is 
> naturally supported and needs no additional features in the query 
> language.  If you have some concrete examples of where reification 
> needs support please coudl you provide them.  See also below.
>
The example you mention  is what has been done so far and is awkward, so 
yes..  i ask syntactical support for reification.. to support this i 
believe it would greatly increase leggibiliy and foster implementation 
of context information in a way that adheres to the model . it  should 
be simple to add :-)

> I woudl also observe that reification is not universally seen as the 
> way to handle this.  Jena has implemented speciifc helper support for 
> reification and goes to some lengths to be correct RDF and have 
> compact DB storage.  Yet the user feedback seems to indicate that a 
> systems scale, the unit of "context" is not the RDF statement - it 
> become unwieldy.

It might or might not be needed or affordable performance wise.
 In theory it could be needed for certain applications, in our P2P 
system the basic unit is the minimal self contained graph (MSG) starting 
from a triple, since that is the basic unit a peer can possibly exchange 
with another (according to the rdf semantics)
as MSG can be fairly large, the amount of extra triples is rather low.
Other applications might require a triple by triple context,  others 
which only assume a single facet of context "which file it came from"  
might be just happy with named graphs :-)

>>
>> SELECT ?name ?mbox ?date WHERE
>>        (?g dc:publisher ?name ?triplecontext)
>>        (?g dc:date ?date )
>>        (?triplecontext  namedGraphs:belongsto 
>> "http://example.com/mynamed.rdf")
>>
>> Another way to expressi this syntactically could be with a 
>> reificationnode(statement) function or a binding say
>>
> So, as I understand it, what you suggest is reification syntax support.

As before yes.. certainly binding a 4th value to the reification node 
would do a lot of good in my opinion
but the specific example i quote above (suing a function instead of 
binding a variable) leaves the door open to different  implements of the 
way to associate a context node to a triple (e.g. by exploring the MSG 
rather than just simply taking the reification node).

>
> It provides a building block - it does not provide CBD or any similar 
> scheme. As your discussion below shows there are several different 
> schemes - and it seems to me that the choice is application dependent, 
> not universal.
>
> One approach to this is via the service description where the service 
> can state what algoroithms it may apply to DESCRIBE results in which 
> circumstances.
>
Agreed that there might be several useful constructs. I was however 
proposing MSG because the theory (albeit simple) shows that they are in 
fact universal and have very useful properties in when  fragments of RDF 
data are exchanged (for example we use them to put digital signature 
that stick to the data as it flows from one graph to another, but it has 
more uses than this). 

Thanks for the attention :-)
Giovanni

Received on Tuesday, 22 February 2005 12:31:45 UTC