W3C home > Mailing lists > Public > semantic-web@w3.org > July 2007

Re: Terminology Question concerning Web Architecture and Linked Data

From: Hans Teijgeler <hans.teijgeler@quicknet.nl>
Date: Tue, 24 Jul 2007 15:22:57 +0200
To: "'Linking Open Data'" <linking-open-data@simile.mit.edu>, "SW-forum" <semantic-web@w3.org>
Cc: "Paap, Onno" <onno.paap@gmail.com>, "Benjamins, Robin" <rxbenjam@bechtel.com>
Message-ID: <001401c7cdf5$c3f3b9c0$6c7ba8c0@hans>

Folks,

In the past week or so I have been deeply puzzled about the fuzz regarding
non-information resources. Here are my two cents of wisdom.

To me the distinction between information and non-information resources is
non-existing, because what you call a non-information resource actually
contains information as well: the information that that 'something' exists,
be it:
- in the past (e.g. Plato)
- at present (e.g. TimBL)
- in a design (e.g. a plant design, with 3D models etc)
- in the future (e.g. my grandgrandson)
- in fantasy (e.g. Spaceship Enterprise)

The notion that TimBL could, in the flesh, be part of an information
representation is too weird. It is what it is: a representation. The most
appealing (to me) definition in the Webster is: "the action or process by
which the mind forms an image or idea of an object".

In our paradigm all of these are instances of PossibleIndividual, and all of
them have a 'system ID' (e.g. ABC123) and an "essential classification",
i.e. membership of a class that lasts from birth to death (e.g. Person (not
Male or Female, because that can change nowadays)). So for example:

	<part2:PossibleIndvidual rdf:ID="ABC123">
		<rdf:type
rdf:resource="http://www.15926.org/2006/02/part2#WholeLifeIndividual"/>
		<rdf:type
rdf:resource="http://www.15926.org/2006/02/part4#Person"/>
		<part2:beginning
rdf:datatype="http://www.w3.org/2001/XMLSchema#date">1955-06-08</part2:begin
ning>
	</part2:PossibleIndvidual>

That's all there is. It's like a peg to which you subsequently hang
information.
Note - The name of that individual is attributed to a temporal part (see
below), because having that name not necessarily coincides with the entire
lifetime of that individual.

The use of a URI#fragID, in which the fragID is the above 'system ID' makes
this identifier globally unique (at least on the Internet, and that is
enough).

Someone else may also have declared TimBL to be an instance of
PossibleIndividual in his/her system. Fine, just another URI#fragID for
TimBL.

Iff I am interested in the information that that other person attached to
his/her TimBL, and iff I am convinced that we both speak about the same
TimBL, then I will link the two with owl:sameAs. That is my responsibility,
and I will suffer the consequences myself (or be hit on the head by others)
if that is incorrect, or insufficiently correct.

Someone spoke about TimBL in his CERN days and the present TimBL as
different things. Rightly so. But as long as the web world refuses (for the
most) to properly timestamp their published information, we will be unable
to know that difference. It is one of those puzzling things about the SW
world how they think they can manage the time component in the
ever-increasing ocean of information over the next 100 years.

Since we work with a 4D model (3D+time) we work with "temporal parts" of
individuals. These temporal parts get their own unique system ID. All
temporal parts of an individual ultimately end at the top of the temporal
decomposition hierarchy: the instance of PossibleIndividual that is also an
instance of WholeLifeIndividual (see above listing). This means that ONLY
the instance of WholeLifeIndividual ABC123 in my system can safely be
declared 'sameAs' the instance of the WholeLifeIndividual denoting the same
TimBL in somebody else's system.

Regards,
Hans

____________________
OntoConsult
Hans Teijgeler
ISO 15926 specialist
Netherlands
+31-72-509 2005
www.InfowebML.ws 
hans.teijgeler@quicknet.nl

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.476 / Virus Database: 269.10.14/912 - Release Date: 22-Jul-07
19:02
 
Received on Tuesday, 24 July 2007 13:26:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 07:41:58 UTC