Re: Statements about statements -- Help needed!

Misha Wolf wrote:
> The section seems to offer two semi-viable options:
>  
> -  Use rdf:ID to identify a statement and then make statements about 
>    the identified statement.
>  
> -  Use some other, application-specific, way to identify statements 
>    but then don't expect anyone else to understand it.
>  

I liked Charles' reply concerning EARL, which took the second approach.
This avoided the semantic problems with RDF reification, and like any 
RDF application specific vocabulary could be understood using standard 
RDF approach:

a) the minimal meaning is given using the RDF Semantics

b) to understand (informally) the intent of any of the terms, click on 
the URI and (hopefully) arrive at a definition (usually with an 
rdfs:comment that gives human readable text)

I feel that the interoperability loss that you seem to fear is a chimera.
When you say "but then don't expect anyone else to understand it" ...
The NewsML vocab itself is only intelligible to people who have bothered 
to try and understand it. The SW gives a method for allowing them to 
understand it, by clicking on the terms. The SW also gives a minimal 
formal semantics to avoid some basic misunderstandings.

If RDF reification worked then what it would offer would be a general 
purpose mechanism for making statements about other statements, noting 
that these other statements have a time and place and a propositional 
attitude and not just a logical meaning. RDF reification does not 
achieve that; and so the current situation is that there is no usable, 
standard, general purpose mechanism for making statements about statements.

(aside:
Personally I think the work done on named graphs by myself, Bizer, 
Stickler and Hayes, addresses this general purpose need; but introduces 
new mechanisms for which there is no standard support.)

So, as whenever you want a module in your code/schema that does 
something general purpose, if there isn't one available that meets your 
needs you have to write your own. It is generally cheaper to write one 
that addresses your needs narrowly scoped, but good to plan it in such a 
way that it could be extended/modified to address more general needs. 
One approach would be to have a class x:Assertion that is perhaps 
defined as a superclass of earl:Assertion. You could then factor out of 
EARL the bits that you wanted, e.g. assertedBy, but not the test case 
specific stuff. This would be a step towards a more general purpose 
mechanism, reusing a bit of EARL, but primarily focusing on the NewsML 
problem and not the general one.

my 2c

Jeremy

Received on Tuesday, 3 January 2006 12:37:20 UTC