OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

topicmaps-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [topicmaps-comment] referring to a topic from outside a TM -- PURL



* Lars Marius Garshol
|
| I think your argument makes sense, but I don't see why you want to
| explicitly allow people to make use subject indicator URIs that
| don't point to the precise subject indicator text.
| 
| Also, note that if all the URIs just point to the same file they
| will be taken to indicate the *same* subject, and thus cause
| merging...

* Thomas B. Passin
| 
| I hope they really meant "URI Reference", so we can get fragment
| identifiers pointing to parts of a document.  

We certainly have to allow that.

| But if not, the wording quoted above means - I think, it's not quite
| definitive - that there would be a different uri for __each__ PSI,

There must be! Otherwise there will be no way to tell them apart (for
a machine), and if this stuff doesn't work for machines it's pretty
much worthless.

| and a server could in fact extract the resource from the same
| "document" if desired, even though the uri would be different.  

Well, yes. It's up to the publisher of the PSI whether they want to
make a single resource with a fragment for each subject indicator, or
separate resources for each subject indicator. As long as it's clear
which Published Subject Identifier points to what Published Subject
Indicator it should all be fine.

| For example, http://tm.com/psi/subclassOf and
| http://tm.com/psi/Person are both regarded as subsidiary resources
| of http://tm.com/psi.  The server can retrieve these subsidiary
| resources however it pleases.

Sure. This is good practice.
 
* Lars Marius Garshol
|
| We do need to be *really* clear on one thing: the subject indicator
| itself (the resource, the text, the thing humans read) is *only* for
| human documentation. It has no other purpose whatsoever. When machines
| do merging they use the URI (also known as the subject identifier,
| precisely for that reason).

* Thomas B. Passin
|
| Yes, I just wonder if machines may get more in the picture in the
| future.

I've been pushing very hard for that for the past year or so, but it's
hard to get people to listen. It just takes time to change the way
people think, I guess.
 
| It may be too legalistic a thought on my part.  If a PSI __must__
| point to a retrievable resource, and suddenly it no longer is
| retrievable, strictly speaking the thing can't be a PSI any more.
| What then should happen to all those places it has been referenced?

It depends somewhat on the usage I'd say. Strictly speaking the URI
(the PS Identifier) still means what it used to mean, but the human
documentation function of the indicator is no longer working. That
makes it risky to use the identifier, but its meaning is still there.

Imagine that this were the 'transitive' PSI, used to indicate that
association types are transitive. Software that uses the PSI to
implement transitivity-related features would still work, but people
would probably gradually stop using this PSI in their topic maps (and
new software).

Similarly for merging. Things using this PSI would still merge, but
the use of the PSI would (should!) decline.
 
| It's better than broken links, though.  Broken links give you
| nothing, but non-retrievable PSIs still mean the same thing, I would
| hope.

Agreed.

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
ISO SC34/WG3, OASIS GeoLang TC        <URL: http://www.garshol.priv.no >



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC