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


>
> * Bandholtz, Thomas
> |
> | See what just has been recommended by PubSubj:
> |
(http://www.oasis-open.org/committees/tm-pubsubj/docs/recommendations/psdoc_
> | 04.htm)
> | "4.4.1 - Every PS Indicator in a PS DocSet shall be identified by, and
> | retrievable through an unique canonical URI.
> | This canonical URI is the corresponding PS Identifier, uniquely defined
in
> | the PS DocSet namespace."
> | Note: ***Every*** PS Indicator, not only the whole set.
>
> * Thomas B. Passin
> |
> | I'm actually against making this mandatory, although it's good
> | practice to do so when possible.  Here's why:
> |
> | 1) Right now, anything retrievable through such a URI must be read
> | and understood by a person, there is no topic maps mechanism to let
> | a processor understand the "meaning" of the PSI.  Being online does
> | not seem to be an runtime requirement for processing, but rather a
> | design time benefit for software and map creators. So any means by
> | which a person can get the information should be ok.
>
> 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...
>

I hope they really meant "URI Reference", so we can get fragment identifiers
pointing to parts of a document.  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, and a server could in fact extract the resource from
the same "document" if desired, even though the uri would be different.  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.

> To me it seems better to require the URI to point directly at the
> text, whatever that means.
>
> 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).
>

Yes, I just wonder if machines may get more in the picture in the future.

> | 2) It prevents people from creating useful PSIs if they don't have a
> | stable website.
>
> What do you mean?
>
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?

> | 3) It would seem to invalidate previously PSIs whose web site goes
> | away for some unfortunate reason, even when the copies of the
> | information are available on many other web sites.
>
> This is a tricky question. The subject identifiers would still mean
> the same thing, but it would be difficult for humans to discover that
> what they do mean. I think that this would be bad practice, but that
> it would be impossible to disallow it.
>
It's better than broken links, though.  Broken links give you nothing, but
non-retrievable PSIs still mean the same thing, I would hope.

Cheers,

Tom P



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


Powered by eList eXpress LLC