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. (01)
>> }
>> 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. (02)
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. (03)
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. (04)
>> 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.. (05)
>
>> 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. (06)
Aha... so for nesting which can change dynamically I in fact need
something else than named graphs. (07)
> Hope this helps. (08)
It definitely helps a lot, thank you. I was hoping you or some other of
the authors would reply. (09)
Jakub Kotowski (010)
>
> 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
>
>
>
>
>
> (011)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (012)
|