Re: named graphs and rdfg:subGraphOf

Pat Hayes schrieb:
> The rdfg vocabulary is intended for
> describing relationships between graphs which already exist.
>
It seemed liked it from the definition and from the motivation of named
graphs but I wasn't sure.

>> }
>> 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.

What I would like to have is a kind of nesting of named graphs so that
the meaning of "f subGraphOf g" is that g consists of triples which are
directly in g and of triples which are in f. This way I would have
grouping of named graphs and could avoid duplication of triples.

So it means that I could use rdfg:subGraphOf for this purpose internally
but would have to "repair" the inconsistencies before publishing them.
But this seems like it would be better to rather invent a new property
or mechanism for this purpose.

>> 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.
I guess I need a bit more training in reading specifications and
definitions..

> 
>> 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.

Aha... so for nesting which can change dynamically I in fact need
something else than named graphs.

> Hope this helps.

It definitely helps a lot, thank you. I was hoping you or some other of
the authors would reply.

Jakub Kotowski


> 
> 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:14:53 UTC