Re: URIs / URLs

Things are even more complicated and the following classical scenario is 
some of food for thought:

You take a photo, develop the negative, make some paper prints of it, at
the same time make a photo-CD, put one of the digital images on the web.

You end up with the following things (resources):
- a negative
- x paper prints
- y digital images in various resolutions (on the photo-CD)
- 1 digital image on the web (identical to one of the images on the
photo CD)
And something else (also a resource)
- the subject of the photo (probably composed of several things
themselves resources)
And again something else (less likely to be called a resource)
- the photo itself (in order to avoid confusion I will call it the
action)


For all these resources you might want to register some information. For
the thing resources probably always where it is located (some of these
will be URL's, other's will be URI's (myNegativeAlbum, page 88, row 5,
number 9)). For the photo itself (might be compared to the action of
making the photo) you might want to say who made it, where and when it
was made and what is on the photo: the subject(s).

Depending on your needs (want you want to do with the photo) you will
"register" some or all of this stuff in a machine, with more or less
metadata associated. 
I can't image one homogenous way of doing so because needs are
completely different (a museum taking a picture of a painting, holiday
photo, a reporter's published photo in a newspaper, etceteras).
One of the things that appear to be relatively stable is the photo
itself (the action). The other (derived) stuff is all, in some way or
another, a representation form of it. The second stable thing is the
subject of the photo.
IMO you are always interested in the subject of the photo (else you
wouldn't have made it). Second if you want to do something with the
photo (action) you will always use one of the representation forms.
If you want to register perfectly everything for everything (the creator
of the photo (action) is not the same as the creator of a scan of a
paper print, the date of the photo (action) is not the same as the day a
digital representation is made), you will end up with much useless
information (for you). So people will never do so. They will only
register what is good enough for them at the time they register the
information omitting the things they might want to know in two years
(deja-vu: S... when or where was that? Or: who is that?).

The easy way (and that's what most people will do, because their needs
are not very deep) is to link (bi-directional) one of the representation
forms (or at least one but maybe all of them) with the subject(s). The
link meaning might be something like "is a picture of - occurs on". This
allows for instance to display the picture with the subject in an easy
way.
But you might associate the subject with the photo (action) and let the
display system select the most appropriate representation form. I can
image an URI for this photo (action) (probably an ID in a system - DB-
Semantic network) but not an URL, probably not even an URN (or it could
be at the terminal part of the URN something like "photo of subject X
taken by Y on DateTimeLambda in PlaceZ").

What I did in Notion System, and what suits 90% of my needs related to
pictures:
- Each electronic representation form is a node in the network (with an
URI)
- Each of these nodes has one or more URL properties (local storage,
web, etc)
- Each of these nodes has a specific derived representation form (low
resolution) for display purposes as icon or preview of the full
resolution picture (itself with one or more URL's)
The other 10% are resolved by a processing model at application level
(business rules for the use of pictures in specific situations).

In resume:
- there will not be a homogeneous way of doing things because people
will only do just what is necessary for their current needs
- we (builders of systems, ontologies, information exchange formats)
have to deal with this situation (good enough or at least the best we
can now - tomorrow - in 10 years) and allow flexibility because needs
change over time
- there are some headaches in perspective


Friendly greetings

Ronald Poell


> Re: URIs / URLs
> 
> From: Seth Russell (seth@robustai.net)
> Date: Tue, Apr 10 2001
> 
> I tend to agree.  It seems to me that there are three major kinds of
> confusions here, then of course there are combinations of those:
> 
> 1) (map\territory) A confusion of the Resource (the real \ or ideal
thing)
> with the entity that represents it in the network.  Sometimes the only
thing
> that exists is a network entity, but sometimes RDF descriptions which are
> netword entities represent real or idea things and sometimes web pages
are
> designed to represent real \ ideal things.
> 
> 2) (use\mention) A confusion of the identifier of the Resource with the
> Resouce itself.
> 
> 3) (identify\retrieve) A URI can do two things: identify a resource,  and
> specify a method of retrieving the network rendering of it.  This dual
> functionality is a source of endless confusion.  When a URI is used as a
> subject or predicate of a RDF statement, it is functioning as an
identifier
> ... but when it is used in the object it may also be describing a method
of
> retrieving a network entity.  Example:
> 
> language: N3
> 
>     :URIdiagram :seeURL <http://robustai.net/mentography/uri.gif>
> 
> language: English
> 
> The M&S specification is one source of our confusions
> see (http://www.w3.org/TR/REC-rdf-syntax/#model ) where it says
> 
>      "There is a set called Statements, each element of which
>      is a triple of the form  {pred, sub, obj}  Where pred is
>      a property (member of Properties), sub is a resource
>      (member of Resources), and obj is either a resource or
>     a literal (member of Literals)."
> 
> I think that should read something more like:
> 
>      "There is a set called Statements, each element of which
>      is a triple of the form  {pred, sub, obj}  Where pred is
>      a property (member of the identifiers of Properties),
>      sub is a resource (member of identifiers of Resources),
>      and obj is either a identifier of a  resource or a literal
>      (member of Literals)."
> 
> language: Semenglish
> Seth
>     semTitle "Seth";
>     uri "http://robustai.net/~seth/index.htm" ;
>     (wants to show you) http://robustai.net/mentography/uri.gif .
> "Seth"
>     identifies Seth;
>     a Literal.
> "http://robustai.net/~seth/index.htm"
>     identifies Seth;
>     a URI.
> semTitle a Property;
>     takesObject Literal.
> NetworkResource
>     subClass Thing.
>

Received on Wednesday, 11 April 2001 07:34:46 UTC