Re: Three solution designs to the first three Graphs use cases

(Mostly repeating what I said on the call, but not everyone was there) 

At the moment, I would like to explore the space where these explicit predicates are there, and see what are the predicates that make sense and the WG would pre-define. I believe that we need one that captures the REST semantics that was discussed, and we would have to have the equivalent of sameAs, and maybe 'tagging', ie, no semantics. In a way, this is a somewhat syntactic reflection of what I raised in November, namely that we will not agree on _one_ semantics, because the association of a URI and a graph seems to diverge in very different views.

We can then have a different discussion, but later, on what 

<g> { ... }

means; it would be the shortcut for 

<g> one-of-our-predifined-predicates { ... }

I am not sure what the one-of-our-predifined-predicates will be; the SPARQL compatibility may suggest to have the 'tagging' predicate there, but I am not sure.

Ivan



On Jan 11, 2012, at 17:55 , Yves Raimond wrote:

> Hello!
> 
>>> MEANWHILE, we have a third solution, where we name the relation
>>> explicitly.   This is the one I prefer.   
>>> 
>>>       UC1 
>>> 
>>>               <http://example.org> rdf:graphState { ... triples recently fetched from there }
>>> 
>>>       UC2 -- either of the styles given above, depending whether the
>>>       harvester wants to publish its copies on the web or not.
>>> 
>>>       UC3 
>>> 
>>>               eg:sandro eg:endorses <uuid:nnnnn>.
>>>       <uuid:nnnnn> owl:sameAs { ... the triples I'm endorsing ... }
>>> 
>>>               or, logically:
>>> 
>>>               eg:sandro eg:endorses { ... the triples I'm endorsing ... }
>>> 
>>>               (Then, I would probably get rid of the curly braces around the default
>>>               graph, so it becomes Turtle with Nesting.)
>>> 
> 
> This has my preference. It would be interesting to understand exactly how it would translate in terms of syntaxes though (it would probably need significant updates to TriG if we want it to not be too verbose).
> 
> Best,
> y
> 
>>> Do those three solution designs make sense?   Any strong preferences
>>> among them?  Are there more use cases that people think the group will
>>> find compelling and which cannot be solved by all three of these
>>> solutions?  (I think the next use case I'd approach would be "Tracing
>>> Inference Results", mostly because it motivates shared blank nodes. 
>>> But I'm out of time for today.)
>>> 
>>>   -- Sandro
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
FOAF: http://www.ivan-herman.net/foaf.rdf