Re: RDF's Mixed-Mode Identifiers

> I wonder if the answer is simpler. 

Yes, there are simpler answers, but they (as you put it) tend to fall
down.  I haven't seen yet where my answer falls down.  

And it's not that complicated: it's just that we need to distinguish
between using a URI to talk about: (1) an information container, (2) the
information it contains (if any), and (3) the subject (when there is one)
of that information.  People freely go back and forth among these uses
of URIs (mostly between the first two, which I didn't try to
distinguish in my previous message, because it was less important),
but for computers to do so is an enormous and unnecessary pain.

> If EARL is talking about whether a web
> page conforms to some content requirement then what you get at that web page
> for a fragment is the thing under discussion.

Hrm.  I'm confused.   The thing under discussion in the EARL report or
in the web page?

I'd guess EARL is talking about the content, here, by way of its
container.  If the content at that URI changed (or was different for a
different users), the EARL information would be wrong.  It's hard to
talk about the content directly, unless you use a text string.
Secure-Hash URIs really mask the difference, since the content and
container are immutably bound.

> The problem case is when I want to talk about a thing that doesn't exist on
> the web, such as my car, and make a claim in EARL that it conforms to the
> roadworthiness standards of the state of Victoria (which also doesn't exist
> on the Web).

That's no problem for my approach: just allocate a container with that
thing as its primary subject.

> The approach we have taken is to say that a web page cannot conform to
> roadworthiness requirements, only a thing that is of type vehicle, and then
> assume that we will infer that in this use of a URI it is merely identifying
> a thing that can met the requirements. Of course this falls down if we want
> to talk about who created it - the web page was made by me, but the car by
> ferrari (or more likely matchbox...).
> 
> FOAF solves this problem by talking about "the thing that has a homepage at
> http://example.net/foo" where 'has a homepage is unambiguous. This can be
> used both for my car and the state of victoria (the publisher of a standard,
> although the standard itself might actually be on the web).

Yes, x:descriptionURIRef is very close to foaf:homepage.  But I think
the notion of homepage is just a little too fuzzy, and easily confused
with web site front pages, splash pages, one's personal "home" page in
one's browser, etc.  So I tried to be more precise, and found myself
prefering the reverse "primarySubject" arc for clarity.  

> The problem then becomes one of identifying statements that were made using
> the assumptions of the original EARL approach and asserting that these
> statements can be relied on if they are transformed in some way (e.g.
> substitute the subject URI of a triple for some RDF that says 'the thing with
> a homepage at this URI').

Right.  First we need to define what the cleaned up, unambiguous form
looks like: perhaps it simply has nodes delabeled to use
primarySubject, foaf:homepage, or whatever.   Then we need to convert
all our old data which uses other forms; that can probably by done
automatically for each ontology -- it's not hard to see which parts of
every EARL document need to be changed.

> (I have oversimplified - there are no "things" on the web, just
> representations of things. In some cases we have more or less general
> instinctive agreement that the representation the Web gives us really is the
> thing - such as the page at http://www.w3.org/ while for other things
> represented on the Web (the person who has a homepage at
> http://www.w3.org/People/Charles - a statement that is already addressable on
> the web as a bit of foaf rdf/xml) the 'real' version isn't the one on the
> web. But I don't think it is that important)

The IETF's conceptualization of web pages as "representations of
objects" is an architectural design error.  Web content is
information; what's transmitted in response to an HTTP GET is a
linguistic expressions conveying information.  Chunks of information
about a thing can serve to represent it (and always do in
object-oriented systems; that's their fundamental technique), but to
imagine they always do is a mistake.  Perhaps that's why you
oversimplified -- because the supposedly-correct terminology doesn't
really fit the situation!  :-)

     -- sandro

Received on Friday, 27 December 2002 07:22:31 UTC