[Issue] Result Properties as... well, Properties

[[[
13:19:05 [chaalsBRS]
NG: Assertion used RDF reification mechanism and vocabulary.
13:19:22 [chaalsBRS]
... side effect was that the result type had to be of type property
13:19:43 [chaalsBRS]
... so the result property was a subclass of type property which is
problematic for lots of tools.
]]] - http://www.w3.org/2002/06/25-erswad-irc#T16-07-00

Why is this problematic? What tools does it break? Can you provide some
test cases and examples of things that break, please?

The value of using the reification properties is that it is clear that
Assertion bags are true statements, and can be factored down via a rule
like:-

{ [ a earl:Assertion; rdf:subject ?x; rdf:predicate ?y;
   rdf:object ?z ] } => { ?x ?y ?z } .

When you start hiding the reification, you're taking away a formal quality
of what an EARL Assertion is (and it's clear that it is an RDF statement),
and there's no need for that, other than the fact that some people
obviously stay awake at night because they think that there are reified
triples under their beds :-)

As DanBri points out, EARL assertions are "scare quoted" because they're
potentially controversial: we want to be able to add context data to them.
However, when you're doing local evaluations, you may not want to bother
with the reification at all; this makes querying much simpler, and it takes
down the amount of data quite significantly. By hiding the reification
under layers of dirt and taking away the formal statement saying "yes, this
is reification" you are making it unclear to such people as to whether they
can use EARL assertions as free standing triples or not.

Note that RDF documents have a kind of implied document level context
anyway: you do not have to read a document as if it is being asserted,
although that is the option that most people will take when reading EARL
documents.

"13:20:14 [chaalsBRS] [NMG:] ... You have a result property (like passes)
that has properties itself." - ibid.

You have always been able to make anonymous result properties in EARL, so
this is no advantage. earl:passes is just a neat little label for [
earl:validity earl:Pass ], in fact.

[[[
13:27:43 [libby] nmg: yes, ok, unlike sbp's versioon, the result objects
are different objects
13:27:48 [libby] ..so can merge ok
13:28:33 [libby] wendy: there is a problem with the merge and pass/fail?
13:29:20 [libby] nmg: before: was an instance of a certain property, so
couldn''t add a meaage to it, because would be a property of all the
properties
13:30:03 [libby] mng: the 'pass' should be an instance of the validity
level - an object
]]]

Perhaps the confusion here simply is just that you thought that one has to
make use of earl:passes and earl:fails. This is not the case. You can--in
EARL 0.95--already make your own little bNoded result properties. In fact,
going via. the anonymous route is more difficult to process, since you have
to query out on the earl:validity arc as well as the rdf:property arc (i.e.
you have two sets of queries jsut to find which things have failed and
which have passed). In any case, your proposal changes absolutely nothing
in this respect (it is neither worse nor better since it is the same),
modulo the point above about hiding reification being a bad thing.

P.S. On "sbp's version": in fact, Aaron Swartz should be credited for the
model.

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://purl.org/net/swn#> .
:Sean :homepage <http://purl.org/net/sbp/> .

Received on Tuesday, 25 June 2002 13:58:02 UTC