- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Sun, 21 Jan 2007 11:21:41 +0100
- To: Michael Schneider <m_schnei@gmx.de>
- Cc: SWIG Web <semantic-web@w3.org>, semantic_web@googlegroups.com
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