Re: URI for language identifiers

Patrick.Stickler@nokia.com wrote:

> > So, it would make sense for the DC folks to make these things
> > explicit,
> > to publish them as an RDF document?
> 
> Well, if they are in fact intending that subjects have a domain
> only of web pages

Well, what I mean is that the subjects of DC statements are intended
to be information resources, but I am willing to be corrected here.


 (and I don't think they are) then yes, it's
> optimal if that knowledge is expressed explicitly (whether or not
> in RDF is another matter).
> 
> However, I don't think that the domain of dc:subject is restricted
> to web pages. I think you're reading alot into the spec there.

What do you think is the domain of dc:subject?



> > > If a URI denotes an abstract concept, you may be able to GET a
> > > representation of that resource. Why not.
> >
> > This is a thing I just don't get about RDF.
> 
> This has nothing to do with RDF specifically. This is the way the
> REST (Web) architecture works. If XTM is to operate on the Web, then
> it must also do so in a way that is compatable with the web architecture,
> and that includes the relationship between URIs, resources, and
> representations.

Well, I don't see that the idea that a resource can also 'be' an abstract
concept is an idea inherent in REST. I know that resource has been redefined
to 'cover' also abstract concepts, but I never understood why that is part
of the REST architecture....


> > I find it VERY
> > strange that
> > a document can be a representation of a dog.
> 
> It's a slippery slope, and there is no clearly drawn line. There
> are many who would agree with you. There are many who wouldn't.
> 
> At present, a representation can be anything. 

Hmm, I thought a representation is at least 'bits and bytes' (data),
what do you mean by 'anything'?


> And there is no clear
> definition of how a representation must relate to the resource itself.
> All that is stated is that, given a URI denoting some resource, an
> HTTP GET can return a representation of that resource.

> 
> I simply consider a representation as some form of content which in
> some way reflects the nature of the resource in some useful manner.
> 
> Some representations will be able to reflect resources much more
> precisely -- and for digital resources, representations may even
> be bit-equal copies.
> 
> For abstract or otherwise non-digital resources, representations
> (which *will* themselves be digital resources) will reflect the
> nature of the resource less precisely.
> 
> And not all resources will have representations available.
> 
> So if I have a URI that denotes a dog, I may HTTP GET a representation
> of that dog which is in fact a digital image or perhaps a video stream,
> or maybe an encoding of its DNA. Whatever. I may have dozens of different
> representations I can choose from.

Sure, but what I don't understand is how RDF solves the problem that
some people might use http://www.w3.org/Consortium/ to identify the W3C
while others might 'make DC statements about it'. In fact, it's
exactly the coexistence of those two things that I think is powerful, because
it allows me to use ordinary (e.g. HTML) web pages to identify subjects.

> 
> And *each* of those representations is a resource in its own right, which
> may (IMO should) be denoted by a URI that is distinct from that denoting
> the resource of which it is a representation -- and servers returning
> a representation may (IMO should) specify the identity of the representation
> in the response.

Hmm, but in REST a URI cannot denote a representation, you cannot address the
'bits and bytes'. ?!
> 
> Still, you *never* can GET a resource itself, even a digital resource.
> You always get a representation. And that representation (unless a bit-equal
> copy) is then a distinct resource.
> 
> > But I guess that is just
> > something to accept as part of the (re-)definition of resource if I
> > want to use RDF.
> 
> Again. This has nothing to do with RDF. This is the web architecture.

But in what way is the redifinition of resource related to Web architecture,
I don't get it. 

[Of course the concept of resource must include services (volume control etc.)
and PUTing etc. to such resources makes a lot of sense to me, but abstract
concepts.....why is it part of the Web architecture that those can also be
resources??]

> 
> As far as RDF is concerned, one need never dereference any URI and never
> get any representation. URIs denote resources and one may use RDF to
> make statements about resources. Representations are entirely outside
> the scope of RDF proper.
> 
> However, where RDF and the web architecture agree is on the fundamental
> principle that URIs should have globally, consistent, unambiguous, and
> immutable meaning.

But you don;t need URIs for that, nor do you need the Web. Maybe that is
what I don;t understand: what is the idea of how RDF interacts/intermingels
with Web architecture (beyond the idea of 'controled vocabulary') ?
> 
> A URI always denotes the same thing, no matter where you encounter it, and
> no matter how many representations might be associated with it, etc.
> 
> URIs are the global constants, the atomic elements, of the web and semantic
> web.
> 
> > Furthermore as it prohibits an author to use
> > "http://www.w3.org/Consortium/"
> > as an identifier for the W3C (since it is a Web page).
> 
> Is it? How do you know? Because you did an HTTP GET and got back
> an HTML instance?

Ok,ok...but we are on the Web, so this assumption seems pretty
normal to me.

> 
> That does not prove that it denotes a web page. The representation
> you got from the server may very well be a web page. Without
> authoritative knowledge about the resource itself, you can't know
> for sure.

But I can use the URI to assert that

http://www.w3.org/Consortium/ dc:Title  "About the W3C"

Is that wrong or right or what ?
> 
> And getting such authoritative knowledge about resources from the
> web authority based on the URI denoting the resource is what I've been
> working on for some time and am in the final stages of completing some
> open source software for accomplishing in a global, scalable fashion.
> 
> (and, yes, RDF is at the heart of it ;-)
> 
> > > > No, in TM land, a URI allways is the address of 'the web
> > page', a URI
> > > > *never* addresses an abstract concept.
> > >
> > > Well, that wasn't my understanding. But if that's true, then TMs and
> > > RDF are even farther apart than I thought.
> >
> > Yes.
> > >
> > > > Then in TMs URIs can be used as subject indicators, refering to
> > > > arbitrary subjects.
> > >
> > > And how do you then make statements about the 'web page' versus
> > > the subject? If you are using the same URI?
> > >
> > > > A key concept is that when the URI of a
> > > > subject indicator
> > > > is dereferenced and the retrieved information resource is
> > > > rendered for human
> > > > perception it should be clear what subject the URI indicates.
> > >
> > > But how do you differentiate between dereferencing the URI as
> > > a subject indicator versus dereferencing the URI as a web page,
> > > and is there any logical relationship between the web page
> > > denoted by the URI versus the subject indicator denoted by the
> > > same URI?
> >
> > > Having this ambiguity seems to make the core machinery alot more
> > > complicated.
> >
> > Here is how we "see the world":
> >
> > There are subjects (anything you want to talk about).
> 
> OK, so TM subject = RDF resource
> 
> > Subjects are
> > represented as topics (the topics are the nodes of the graph that is
> > 'produced' from a topic map). Topics have properties that say what
> > the subject of the topic is.
> >
> > Topic Maps are not tied to the Web or URIs conceptually, but it is
> > the most known application of them at the moment. So, when
> > applying topic
> > maps to the Web world, there are two properties that handle the use
> > of URIs: SubjectIndicators and SubjectAddress.
> >
> > The value (if any) of the SubjectAddress property is a URI
> > and if a given
> > topic exhibits a value for this property, then the topic is a
> > surrogate
> > for the subject that is the resource (in the sense of Web page, never
> > abstract concept).
> >
> > The value (if any) of the SubjectIndicators property is a
> > list of URIs,
> > and each Web resource (again: in the sense of Web page) addressed by
> > the URIs is called a subject indicator (or "subject
> > indicating resource")
> > for the subject that the topic represents.
> 
> topic  == subject    ?
> topic  -> subject    ?
> topic  -> subject+   ?
> topic+ -> subject    ?

In a topic map, a subject is allways represented by a single topic,
that is the heart of topic maps, actually.

> 
> > So, the core machinery is actually as simple as "nodes with properties
> > the 'say' what the node represents".
> >
> > This is not the whole story of course, but I hope you get the idea.
> 
> Well, I found the original TM spec pretty simple and straightforward,
> but XTM has left me continually confused, and I've read through it
> numerous times.

Oh? I think it is much simpler than the former ISO13250
> 
> How about a simple example. Here are two URIs, the first denotes
> the person John Doe and the second denotes an image of the
> person John Doe.
> 
>    ex:John     rdf:type ex:Person .
>    ex:John.jpg rdf:type ex:Image .
> 
> Then, I set my web server up so that if one does an HTTP GET on
> ex:John, it returns a copy of ex:John.jpg as a representation
> of ex:John. If one does an HTTP GET on ex:John.jpg, it returns
> a copy of ex:John.jpg as a (bit-equal) representation of
> ex:John.jpg.
> 
> Now, I can differentiate between the person John Doe and the image
> of the person in various statements I make:
> 
>    ex:John ex:firstName "John" .
>    ex:John ex:lastName "Doe" .
>    ex:John dc:created "1966-03-31"^^xsd:date .
>    ex:John ex:hasRepresentation ex:John.jpg .
> 
>    ex:John.jpg dc:title "Image of John Doe" .
>    ex:John.jpg dc:format "image/jpg" .
>    ex:John.jpg dc:created "2003-03-10"^^xsd:date .
>    ex:John.jpg ex:representationOf ex:John .
> 
> The fact that ex:John is not a "web page" in no way prevents me from
> getting a representation of the resource (person). The URI ex:John
> does not denote both a person and a web page. It only denotes a person.
> The fact that HTTP GET on ex:John returns a web document in no way
> changes the denotation of ex:John from being the person.
> 
> Thus, there is no restriction against a URI denoting a non-web-accessible
> resource. And it seems to me that XTM presumes that such a restriction
> exists, and that is the motivation for having the subject/address dichotomy
> and introducing ambiguity into the denotation of URIs.

The denotation is not ambigous but there are two *ways to use* of URIs
> 
> And I say XTM, not TM, because this dichotomy is an XTM invention not
> present in the original TM model. 

That is not true, the use of addresses (not only URIs) as addresses for
information resources *and* as identifiers for subjects is at the core
of topic maps.

> XTM first did the right thing by
> adopting URIs, and then broke everything by not preserving globally
> consistent, unambiguous, and immutable denotation.

Hmm, what exactly do TMs brake?


Jan


> 
> Thus, there is no *need* to make any distinction between the resource
> denoted by a URI and some "subject" which that resource ambiguously
> also denotes. If you want to talk about a subject, give it a URI and
> just talk about the subject. Simple.


> 
> Patrick

-- 
Jan Algermissen                           http://www.topicmapping.com
Consultant & Programmer	                  http://www.gooseworks.org

Received on Tuesday, 1 April 2003 16:43:07 UTC