Re: named graphs and rdfg:subGraphOf

Hi,

you might want to take a look at networked graphs a declarative 
mechanism for describing relationships between graphs:

there is a WWW paper:
http://www.uni-koblenz.de/~staab/Research/Publications/2008/NetworkedGraphs-WWW2008.pdf

an open source implementation on top of Sesame:
http://isweb.uni-koblenz.de/Research/systeme/NetworkedGraphs

and an example application:
http://isweb.uni-koblenz.de/Research/systeme/semap

Steffen





Pat Hayes schrieb:
> 
> On Oct 7, 2009, at 3:46 PM, Jakub Kotowski wrote:
> 
>> Hello,
>>
>> I am trying to understand the definition of the rdfg:subGraphOf property
>> from [1,2]. It says that:
>>
>> <f,g> is in IEXT(I(rdfg:subGraphOf))  iff
>> rdfgraph(f) is a subset of rdfgraph(g)
>>
>>
>> What confuses me is probably the "syntactic part" of the definition:
>> rdfgraph(f) is the ("syntactical") set of triples of the named graph f.
> 
> Yes, graphs are indeed syntactic entities.
> 
>> I am wondering whether it means that if rdfgraph(g) does not contain all
>> the triples from rdfgraph(f) I can infer them - so that after the
>> inference proces I'll get a new, enriched rdfgraph(g) for which the
>> condition already holds (rdfgraph(f) is a subset of rdfgraph(g))...?
> 
> It was not intended to have this kind of 'procedural' interpretation, 
> but if you had a system which tried to generate graphs from their 
> descriptions, then this might make sense. It would not be inference, 
> however, but something more like a graph construction process.
> 
>> Instead of this description I would almost rather like to ask whether it
>> means that the triple f rdfg:subGraphOf g entails:
>> g {
>>     rdfgraph(f)
>>     plus whatever was in g before
> 
> Before what, exactly? You seem to have a process or procedure in mind, 
> but I do not follow what it is. The rdfg vocabulary is intended for 
> describing relationships between graphs which already exist.
> 
>> }
>> But that doesn't seem to be correct because entailment is not defined
>> over a set of named graphs.
>>
>> The alternative would be that a knowledge base containing:
>>     the triple        f rdfg:subGraphOf g
>>     the named graph        f
>>     the named graph        g ...(the original, not enriched one)
>>
>> is inconsistent because rdfgraph(f) is not a subset of rdfgraph(g) but
>> the triple f rdfg:subGraphOf g is asserted.
> 
> Well, indeed, this combination as described is inconsistent. Now the 
> question is, what to do about this inconsistency when it has been 
> detected, if anything. One possibility is simply to report it as an 
> inconsistency. Another is to try to 'repair' it, by changing the world 
> so as to make it consistent. This could be done in various ways: the 
> subgraph assertion could be rejected, for example, or the graph named g 
> could be expanded to include the triples of the graph f. The formal 
> semantics does not specify which of these, if any, is correct or 
> appropriate: it simply specifies the inconsistency. What can be done 
> depends in practice largely on who has ownership of the various graphs 
> involved.
> 
>> Well, this alternative maybe
>> does not even make sense because a set of (accepted) named graphs is
>> defined to have the usual RDF semantics of the merge of the respective
>> graphs.
>>
>> On the one hand the first interpretation would seem more plausible
>> because it would make the rdfg:subGraphOf property usable as a way of
>> nesting named graphs, on the other hand, the provenance motivation for
>> named graphs seems to be in favour of the alternative interpretation
>> which sees the property as rather descriptive.
> 
> Certainly, the property is intended to be purely descriptive, as far as 
> the normative specification is concerned.
> 
>> After all, if a graph
>> changes because of inference (inferred triples are added) then the new
>> graph should probably be associated with provenance information which
>> documents that it was inferred and possibly how.
> 
> Certainly it will be a different graph, one with a different name. Named 
> graphs are not intended to be names of *dynamic* graphs. The usual rules 
> of 'cool URI' usage apply here just as they would to any other document 
> or information resource.
> 
>>
>> At least the following is true, right?
>>
>> :f rdfg:subGraphOf :g does not hold if :f and :g are specified as 
>> follows:
>>
>> :f {
>>     :a rdfs:subclassOf :c .
>> }
>>
>> :g {
>>     :a rdfs:subclassOf :b .
>>     :b rdfs:subclassOf :c .
>> }
>>
> 
> That is correct. In this case f is a subgraph of the RDFS closure of g, 
> but not of g itself.
> 
> Hope this helps.
> 
> Pat Hayes
> 
>> Am I just making things too complicated and overlooking something?
>> By the way, esentially this question has already been asked but
>> unfortunately left unanswered:
>> http://lists.w3.org/Archives/Public/semantic-web/2006May/0108.html
>>
>> Best regards,
>> Jakub Kotowski
>>
>>
>> [1] Named graphs, provenance and trust Export
>> Jeremy J. Carroll, Christian Bizer, Pat Hayes, Patrick Stickler
>> In WWW '05: Proceedings of the 14th international conference on World
>> Wide Web (2005), pp. 613-622.
>>
>> [2] Named graphs
>> J. Carroll, C. Bizer, P. Hayes, P. Stickler
>> Web Semantics: Science, Services and Agents on the World Wide Web In
>> World Wide Web Conference 2005------Semantic Web Track, Vol. 3, No. 4.
>> (December 2005), pp. 247-267.
>>
>>
>>
> 
> ------------------------------------------------------------
> 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 Thursday, 8 October 2009 16:22:07 UTC