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

The model is OK, but we don't like saying "subject, predicate, object" when
they actually have a particular meaning, and the freestanding relationship
doesn't care which one we think is the subject...

defining them as explicit thigns also lets us annotate what they mean, which
is useful.

I can't comment on which tools choke on the current model - I don't know. I
hope someone can. I am not sure that this is a long-term issue, but not
having to face it isn't so terrible either...

we can always factor your assertion which was
  { [ a earl:Assertion; rdf:subject ?x; rdf:predicate ?y;
     rdf:object ?z ] } => { ?x ?y ?z } .
as
  { [ a earl:Assertion; earl:testObject ?x; earl:testResult ?y;
     earl:otherThing ?z ] } => { ?x ?y ?z } .
or as
  { [ a earl:Assertion; earl:testObject ?x; earl:testResult ?y;
     earl:otherThing ?z ] } => { ?y ?x ?z } .
if we want to...

Cheers

Chaals

On Tue, 25 Jun 2002, Sean B. Palmer wrote:


  [[[
  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/> .


-- 
Charles McCathieNevile    http://www.w3.org/People/Charles  phone: +61 409 134 136
W3C Web Accessibility Initiative     http://www.w3.org/WAI  fax: +33 4 92 38 78 22
Location: 21 Mitchell street FOOTSCRAY Vic 3011, Australia
(or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France)

Received on Tuesday, 25 June 2002 18:02:15 UTC