Bijan Parsia wrote:
On May 16, 2007, at 11:15 AM, Phillip Lord wrote:
"EJ" == Eric Jain <[EMAIL PROTECTED]> writes:
EJ> Just catching up on reading papers :-)
EJ> <http://www.biomedcentral.com/1471-2105/8/S3/S2>
EJ> "It is also useful to know who believes something and
EJ> why. However, there is no standard way of expressing such
EJ> information about a statement [...]"
EJ> Reification?
That's who, not why.
No, you can do both with reification.
The Gene Ontologies evidence codes are and
references are much closer.
Also, I am not sure of the semantics of reification.
RDF reification has very little to no built in semantics. What it
provides is a standardized syntax.
Does it mean "I
made this statement", "I believe this statement" or "I am the person
responsible for the evidence on which this statement is based".
It doesn't provide any of these propositional attitudes, but you could
layer these on top of reification, i.e., use reification of a triple as
the object of an "I believe..." statement. You could make a little
"belief object" which had properties for who, when, why, to what degree,
etc and "content" which would be the reified triple.
You can, of course, role your own reification mechanism, and that's what
one typically does, e.g., to get n-ary predicates (or for things where
one might have used an n-ary pred). Some stores (to my surprise, e.g.,
Jena) will take reified triples and condense them into a nicer internal
form for querying (obviously this wouldn't help with a role-your-own).
In either case you have to supply the semantics of the operators
separately, either through axioms or a special tool support.
OWL 1.1 provides a mechanism for putting annotations directly on axioms
(which in the RDF mapping is encoded using RDF reification), with no
specified semantics. One could use these as a hook, or just extend the
XML or functional syntax directly.
You could also use literals.
However, all this *supports* your point. There *IS* no standardized way
to represent this sort of information. There is a more or less standard
(and widely loathed) hook/technique upon which you could build a
standard mechanism for representing this sort of information.
It's worth making sure everyone's aware of the RDF Semantics spec text
on this, http://www.w3.org/TR/rdf-mt/#Reif to avoid reading too much
into the reification vocabulary. Specifically,
"""Note that this way of understanding the reification vocabulary does
not interpret reification as a form of quotation. Rather, the
reification describes the relationship between a token of a triple and
the resources that triple refers to. The reification can be read
intuitively as saying "'this piece of RDF talks about these things"
rather than "this piece of RDF has this form"."""
The best health-check here is probably for anyone planning to use
rdf:predicate, rdf:subject, rdf:object and rdf:Statement to write out
some test-cases in which the values of these properties are further
described using owl:sameAs. And then to make sure that substitution of
equivalents into the graph still fits the intended meaning of the
extended reification vocabulary.
<rdf:Statement>
<rdf:subject rdf:resource="http://example.org/doc1.html"/>
<rdf:predicate rdf:resource="http://purl.org/dc/elements/1.1/source"/>
<rdf:object
rdf:resource="urn:lsid:ncbi.nlm.nih.gov.lsid.biopathways.org:genb"/>
<rdf:object
rdf:resource="urn:lsid:ncbi.nlm.nih.gov.lsid.biopathways.org:genc"/>
</rdf:Statement>
<rdf:Description
rdf:about="urn:lsid:ncbi.nlm.nih.gov.lsid.biopathways.org:genb">
<owl:sameAs
rdf:resource="urn:lsid:ncbi.nlm.nih.gov.lsid.biopathways.org:genc"/">
</rdf:Description>
Excuse my blundering about in an example from a domain I don't
understand, the intent was just to give two URIs, such as the LSIDs
here, that supposedly denote the same thing. So in this example this
gives us two rdf:object properties of the statement. The roll-your-own
extensions approach just needs to fit in with this state of affairs, ie.
in general steer clear of anything designed to talk about the specific
form of the described RDF fragment...
cheers,
Dan
