Re: Restricted Metadata Inheritance by Named Graphs?

I agree with this.

You have 2 problems:

1) Express relations between graphs
   I think this is clear what it is.
   What rdf:type is graph? I would use this
   http://www.w3.org/2004/03/trix/rdfg-1/
   The relation you are looking for is "imports" and should
   have domain and range rdfg:Graph. It doesn't exist yet afaik.

2) Construction of graphs
   There should be subclasses of rdfg:Graph which would be for
   description of constructed graphs (or just one subclass
   "ConstructedGraph" which would be union of all methods used on it).
   similar to OWL (aka union, intersection, enumeration...):
   http://www.w3.org/TR/owl2-primer/#Advanced_Class_Relationships
   Such constructed graphs could be defined using SPARQL queries, but
   I wouldn't advise that, because why use another syntax, not native
   description in RDF? SPARQL could be easily generated from such
   constructed graphs, not the other way.
   Also note that description of such graphs would use terms from 1).

In fact this whole framework could be alternative to SPIN (RDF SPARQL
query vocabulary) - native RDF description of graph relationships and
operations on them.
As I was saying on #swig yesterday, this could be very useful for access
control lists (among other things).

The problem is the terms for this (not even talking about a spec.) are
not yet defined. I would like to take part in modeling such ontology and
I hope it is going to be community developed.

Best,
Jiri Prochazka

Steffen Staab wrote:
> Hi Christoph,
> 
> I think that you deal here with two different problems:
> 
> One problem is that you may want to "copy" / "inherit" / "whatever you
> call it" data. You can use rules for this, we use Networked Graphs:
> http://west.uni-koblenz.de/Research/systeme/NetworkedGraphs
> 
> The second problem is a general one in the semantic web, namely that the
> combination of data from different sources (with different trust values)
> may lead to inconsistencies or propositions of varying trust values.
> Here is a paper you might want to read:
> Schenk, Simon (2008): On the Semantics of Trust and Caching in the
> Semantic Web. In: ISWC2008: 7th International Semantic Web Conference.
> 
> Cheers
> Steffen
> 
> Christoph LANGE schrieb:
>> Dear all,
>>
>>   in certain knowledge bases I have encountered metadata inheritance
>> -- one
>> resource A pointing to another resource B, saying "inherit B's
>> metadata".  So
>> far, there knowledge bases have not yet assumed an RDF semantics for
>> their
>> metadata, but I'd be interested in changing that.  Now I wonder how to
>> appropriately represent this kind of inheritance.
>>
>> In the original application, the metadata of a resource are a fixed
>> record
>> attached to the resource.  The metadata are mostly literal-valued
>> (Dublin Core
>> and similar), but some are also URI-valued, pointing to other resources.
>>
>> A naïve approach to inheritance would be a rule
>>
>> {  ?resource :inheritsMetadata ?otherResource .
>>    ?otherResource ?property ?value . }
>> =>
>> { ?resource ?property ?value. }
>>
>> This would, however, easily cause trouble in an RDF world, as
>>
>> 1. the two resources might be of different types, which might be
>> disjoint in
>>    an OWL ontology, but what if ?resource inherits rdf:type from
>>    ?otherResource ?
>> 2. what if an inherited property is an OWL FunctionalProperty but has
>>    different values on ?resource and ?otherResource ?
>> 3. what if the metadata explicitly stated in the scope (e.g. the same XML
>>    document) of ?otherResource are fine, but somebody else externally
>> writes a
>>    triple ?otherResource :evilProperty "value" ?
>>
>> I consider (3) the most serious problem.  A solution might be named
>> graphs.
>> I.e. the metadata that the author of ?otherResource explicitly
>> provided, and
>> that (s)he considers safe, would be put into a named graph G, and the
>> :inheritsMetadata property would not point to ?otherResource but to G.
>>
>> Has that problem ever been dealt with?  Is there any
>> publication/specification
>> that you could recommend me to read?
>>
>> Cheers, and thanks in advance,
>>
>> Christoph
>>
>