Re: In RDF what is the best practice to represent data provenance (source)?

Michael,

You say there is a distinction between "atomic resources" in a  
domain, and relationships between them. Such a distinction is  
artificial. The "atomic resources" in reality are quite literally not  
atomic, and if you squint the right way, any relationship can be seen  
as a resource of its own. The distinction is just an artifact of your  
modelling.

So, I agree with ChrisR: If you feel the need to make statements  
about relationships, then maybe the modelling is not adequate to your  
use case, and the relationship ought to be turned into a resource of  
its own. Some related advice is found in [1].

Yours,
Richard

[1] http://www.w3.org/TR/2004/WD-swbp-n-aryRelations-20040721/



On 19 Jan 2007, at 19:07, Michael Schneider wrote:

> Tim Berners-Lee wrote:
>
>> The RDF spec's version of reification is not just incomplete but  
>> broken, as it does not quote the identifiers used, it uses them.
>
> Oh, I see: The original intention behind RDF is really to provide a  
> "quoting" feature, meaning that a reified statement like
>
>   r a rdf:Statement; subject s; predicate p; object o .
>
> should denote the /syntactic triple/ "s p o" within an RDF graph. I  
> now see it in the RDF semantics spec [1, section 3.3.1]:
>
>   "Semantic extensions MAY limit the interpretation of these so that
>   a triple of the form
>
>     aaa rdf:type rdf:Statement .
>
>   is true in I just when I(aaa) is a token of an RDF triple in some
>   RDF document, and the three properties, when applied to such a
>   denoted triple, have the same values as the respective components
>   of that triple."
>
> Apologies to Chris and Richard! I had a complete different  
> understanding of reification.
>
> Perhaps, you give me the chance to explain, how I understood  
> reification until now, and then, I would like to here from you, if  
> this alternative understanding is something you can better live  
> with. Accepting this view on reification would, however, result in  
> a complete re-interpretation of this construct.
>
> My starting question is: How can I talk about the /relationship/  
> between two resources, which is denoted by some syntactic triple  
> within a RDF graph? IMHO, the primary use of RDF in the Semantic  
> Web is to describe resources, which exist in some domain. I do this  
> by telling the
> resource's properties, and by telling the relationships, which hold  
> between such resources. But, I not only want to describe concrete  
> things ("atomic resources"), I also want to describe the  
> relationships between such things. Until now, I understood  
> reification as the means in RDF to do this.
>
> From a semantical point of view, this seemed pretty convincing to
> me. RDF semantics [1] says in section 1.2:
>
>   "The semantics treats all RDF names as expressions which denote.
>   The things denoted are called 'resources', following [RFC 2396],
>   but no assumptions are made here about the nature of resources;
>   'resource' is treated here as synonymous with 'entity', i.e. as a
>   generic term for anything in the universe of discourse."
>
> So, for each RDF graph G, for each interpretation I of G, and for  
> each URI ("name") u used within G, there must exist some resource I 
> (u) within the interpreting domain, which is denoted by u. So, even  
> for a reified statement r in G, like the one given above, there  
> must exist some matching resource I(r) within the domain ("r" is  
> meant to be an URI here).
>
> The question is, what this resource actually is? What is known is  
> that I(r) has the following properties:
>
>   * the value of its property I(rdf:subject) is I(s)
>   * the value of its property I(rdf:predicate) is I(p)
>   * the value of its property I(rdf:object) is I(o)
>
> The URI 'rdf:subject' would then denote that relation within the  
> domain, by which we access the subject of some relationship kind of  
> resource. And analog for the other two property URIs. I would  
> further postulate that those three properties are restricted in a  
> way, that they can only occur as properties of relationship kind of  
> resources. Under these conditions, I can conclude that I(r) really  
> must be a relationship, not an atomic thing. And I can also  
> conclude that this relationship holds between the resources denoted  
> by the URIs 's' and 'o', together with a property denoted by URI 'p'.
>
> So, in my opinion, it is pretty natural to think of reification as a
> means to represent relationships, which "live" within the  
> interpreting domain, and not so much as a means for representing  
> triples of the interpreted RDF graph.
>
>> There is an outstanding RDF issue about it.
>> cwm does a reification which is not broken,  using a similar but  
>> different ontology.
>> I think reification should be dropped from a future RDF spec.
>
> Yes. But, with a complete change of meaning in the form proposed  
> above, would you give reification a second chance? If not, can you  
> tell me some alternative means to reference (and annotate)  
> relationships within a domain? I do not see a second candidate for  
> providing this functionality.
>
>> I think n3's literal graphs like   <doc1> :says  
>> { alan :mother :joan }.   should be added as an extension.
>> In RDF/XML a parsetype="quote" option would do it.
>> Calling them "names graphs" as caught on but they are really graph  
>> literals, as they don't have to have a URI.
>> To force them to have a URI would be like forcing strings,  
>> numbers, or lists to haver URIs.
>>  Tim
>> /me wonders what semantic-web@googlegroups.com is
>
> This is Google's Semantic Web group, a very low-frequency group,  
> where this thread started originally:
>
>   Group: http://groups.google.com/group/semantic_web
>   Thread: http://groups.google.com/group/semantic_web/browse_thread/ 
> thread/d820f138af640570
>
>> and what its relationship is with antic-web@w3.org
>
> I don't know about this mailing list, sorry.
>
>
> Best regards,
> Michael
>
> [1] RDF Semantics: http://www.w3.org/TR/rdf-mt
>
>

Received on Sunday, 21 January 2007 10:22:01 UTC