Re: live meaning and dead languages

Thanks a lot for the clarifications
I am not sure I knew that was the case
but I think I am clear with the notion of timestamp, whatever way that is
dealt with

I presume the representation of the relationship between
these many URIs that point to the same resource (to reduce ambiguity) should
also be  specified somewhere?

thanks again
best

PDM

On Mon, Feb 9, 2009 at 11:01 PM, Frank Manola <fmanola@acm.org> wrote:

>
>
>>
> Paola--
>
> If I understand what you say above, I don't think it's entirely correct.
>  Specifically, I don't think the relationship between URIs and what they
> point to is as straightforward as you seem to be saying.  While it's true
> that you can have a URI that points to a resource (like a definition) that
> changes, you can also have a URI that points to a resource (like the same
> definition) as of a specific point in time (or as in some non-temporal
> context).  You'd want these to be distinct URIs because they refer to
> different resources (one is "the current definition of X" and the other is
> "the definition of X as of Y".  The Architecture of the World Wide Web" (
> http://www.w3.org/TR/webarch/) describes an example that illustrates this.
>  Section 2.3.2 says "In this story, there are two resources: "a report on
> the current weather in Oaxaca" and "a report on the weather in Oaxaca on 1
> August 2004". The managers of the Oaxaca weather site assign two URIs to
> these two different resources. On 1 August 2004, the representations for
> these resources are identical.  That fact that dereferencing two different
> URIs produces identical representations does not imply that the two URIs are
> aliases."  The URIs that point to W3C specifications illustrate the same
> idea.  There is one URI that always refers to the "latest version", and
> separate URIs for each dated version.  As of a given date, there will be a
> pair of URIs that return the same representation, but the two URIs refer to
> different resources.
>
> As far as the other points are concerned, it's certainly true that we have
> to deal with changing definitions (and data) in the Semantic Web, and that
> this complicates things. I don't think this is exactly an insurmountable
> task.  Of course, we have to take time (and other contexts in which things
> can change) more explicitly into account, and maintain more metadata to
> describe those contexts, but we already have to do this in some
> circumstances.  For example, in an operational database we tend to expect
> the definitions to remain static and the data to be the latest available,
> but in a database containing historical information we have to deal
> explicitly with time, both in the form of different data values (at
> different times) for the same item, and potentially in the form of different
> definitions for the items (the same holds true in merging heterogeneous
> databases).  All this complicates things, but that's part of dealing with
> change, and it's not really a new problem.  The Semantic Web just forces us
> to face the problem more directly.  At least that's MHO.
>
> --Frank
>
>
>
>>
>> On Mon, Feb 9, 2009 at 12:00 AM, Frank Manola <fmanola@acm.org> wrote:
>>
>>
>>
>> All this seems reasonable enough, but we also need to remember that in
>> these respects the SW isn't going to be all that different from lots of
>> other "representations" that we use and rely on all the time (databases,
>> maps, books, etc.), and which are perfectly reasonable representations of
>> what the purport to depict for most purposes.  Using your example, a map may
>> not be the territory, and we need to have in the backs of our minds the fact
>> that things may have changed since the map was made (or that the map is
>> inaccurate in some respect), but that doesn't mean we don't rely a lot on
>> maps and find them extremely useful.  Moreover, since we know we're going to
>> rely on maps being a good representation of the territory (that's what we
>> make them for), part of the "engineering" that goes into them involves
>> making them as reliable as possible, and keeping them up to date.  It also
>> involves creating artifacts like benchmarks that we specifically try to make
>> sure stay where they were when the map was created, while everything else is
>> changing independently (benchmarks can move, or disappear too, but we make
>> specific efforts to reduce those occurrences), to act as reference points.
>>  We also recognize (and tend to rely on) that things depicted on the map
>> change at different rates, and to different extents.  For example, when
>> looking at a highway map, I'm apt to be a lot more ready to believe that a
>> bridge along the route between Philadelphia and Baltimore has been torn down
>> since the map was created than to believe that Philadelphia has disappeared
>> (or moved into New Jersey).  The point is that some things (or aspects of
>> those things), even if they change, aren't necessarily going to change fast
>> enough so that assuming they're reasonably static generates significant
>> errors (in whatever).
>>
>> --Frank
>>
>>
>


-- 
Paola Di Maio
**********************************