Re: URI etymology

> It is a problem in that those representations are resources in
> their own right.

It's not a problem, just another facet of the discussion. In EARL [1]
for example, we evaluate Web content, and we evaluate Tools and so
forth. When you make an evaluation about some generic Web content,
you're basically saying that you're evaluating the content returened
from some resource on a certain date. Hence, the property that links
to this defines this, and a new resource is created. In EARL it's not
a problem at all - it's part of the mechanics of how things work.

However, there are added complications, as you say. One such thing is
that fact that people can sent accept HTTP headers, and CC/PP
profiles, to get a different representation of the resource. EARL
currently lacks properties to describe these mechanisms, but is
extensible so can easily include them in the future.

> Yet, if you want to process both people and images in your
> SW app, you run into trouble when you want to tell that the
> person and the image have different names, [...]

No, this is something which is highly contextual, and the main stream
of my disagreement. The following can model this situation:-

   :x a :Picture;
      :returnedFrom <>;
      :date "2001-03-17";
      :containsARepOf [ a :Person; :name :y ] .

There is nothing wrong with creating new URIs to identify a resource
which may exist only temporarily or conceptually inside a system, and
then get processors to understand the distinction.

> In the case of documents defining namespaces, there might be
> more than one, each with their own RDF descriptions. [...]

Once again, this is no problem, unless you somehow believe that what
you get back from a namespace upon dereferening it is the "one true
definition" of the terms in that namespace; utter nonsense.

> I do know that this sort of reasoning has a somewhat puritanian
> feel to it, [...]

Not really; they're good issues, but it's so easy to run afoul of
pedantry while chasing them.

> but once you have a SW running where other people, or worse
> yet, applications written by other people, need to use your data,
> you start to bump into the finer grained semantic distinctions. It
> seems to me that thinking ahead is the easiest way to avoid future
> confusion.



Kindest Regards,
Sean B. Palmer
@prefix : <> .
:Sean :hasHomepage <> .

Received on Tuesday, 12 June 2001 10:06:46 UTC