Re: Splitting vs. Interpreting

(apologies for the resend, Sean - missed the cc's in the first response)

On Tue, Jun 16, 2009 at 3:23 PM, Sean B. Palmer <sean@miscoranda.com> wrote:

> You write about ambiguous and specific references here:
>
> http://dbooth.org/2007/splitting/
>
> When I worked on EARL in 2002, we had to solve httpRange-14, and we
> did it in a practical way which your splitting document reminds me of.
>
> We might want to evaluate a tool of some kind in EARL, say the W3C
> Validator. But then we didn't know whether validator.w3.org was the
> tool itself or a page about the tool. That's httpRange-14 in a
> nutshell, before it was “solved” with the 303 hack.
>
> So what we did was this:
>
> <http://validator.w3.org/> earl:tool _:Validator .
>
> The clever bit is that the earl:tool property says: if the subject is
> a Document (i.e. an IR), then the object is the Tool described by that
> document; whereas if the subject is a Tool, then the object is simply
> the same thing as the subject.


This isn't quite the same idea as splitting (which is more problematic).
Here the ambiguity is maintained due to not completely constraining the
interpretation of http://validator.w3.org/. Essentially, you are asserting,
as a consequence of the use of earl:tool, that http://validator.w3.org/ is
of type unionOf(tool document). However, assuming that tool and document are
disjoint, you can't use http://validator.w3.org/ both in one place which
forces it to be of type document (e.g as the target of foaf:page), and
another which forces it to be a tool (e.g. http://validator.w3.org/ :runUnderOS
:linux). Doing so would lead to a logical consistency.

Dave's splitting proposal, OTOH, lands up recapitulating the class/instance
distinction with another mechanism, one which doesn't offer the same support
for reasoning that that the existing SW stack offers.

What I like about your solution is that you at least admit that documents
and services are different sorts of things, instead of using a term
inconsistently. If *everyone* used http://validator.w3.org/ in this way, it
could work.

But if everyone is to use the same scheme, it would seem better to me to
define a new type that made directly clear the nature of
http://validator.w3.org/ as being a sort of service which can do two
different things a) respond with a report about conformance to RDF syntax of
a supplied document and b) respond with a page that documents how (a) works.
Then have two *unambiguous* properties a) earl:tool that relates
http://validator.w3.org/ to an entity whose type is tool, and b) foaf:page
that relates to a document. It would be helpful to document, as well, that
the tool (b) generates a new instance of document, each time it is "run".

-Alan


>
>
> And as you can imagine, this is extensible to interpreting ambiguous
> resources in all kinds of ways. Now the TAG finding says that it's
> removed a certain level of ambiguity, but there are other ambiguities
> one might want to resolve when a page 303s and then still doesn't
> define carefully what's at the end of it. So the EARL method is much
> more practical.
>
> You might also want to think a bit harder about statements such as
> “there is no architectural need for Person and IR to be considered
> disjoint”. Consider if you were using Facebook and it started
> conflating people with groups and games and so on. But of course
> people break the rules of the web until they matter, and since there's
> no Semantic Web User Agent this rule doesn't matter.
>
> I'm not saying that the TAG finding should be canned because you can
> use the kind of interpretation properties that I've described as a way
> around it. The point is rendered moot by various architectural
> problems. But you ought to compare the 2002 and 2009 architectural
> solutions carefully.
>
> --
> Sean B. Palmer, http://inamidst.com/sbp/
>
>