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

 


Help: OASIS Mailing Lists Help | MarkMail Help

tm-pubsubj message

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


Subject: RE: [tm-pubsubj] [Fwd: NISO-Sponsored INFO URI Scheme Published]



Patrick

> I would amend your interpretation to read:
>
> "The Publisher of a Published Subject Identifier must provide a
> non-ambiguous mechanism giving access to a unique human-interpretable
> Published Subject Indicator."

Certainly more accurate than my proposal. I think we are on the same page,
and I fully agree with the points below, too.

> The publishers cited, such as NASA Astrophysics Data System, Library of
> Congress, etc., already have legacy systems in place that provide the
> "unique human-interpretable Published Subject Indicator."
>
> A few other quick points:
>
> First, there is a cost associated with requiring dereferenceable
> identifiers, as noted in the document you cite above:
>
> > Further, if HTTP URIs were used to provide resource representations,
> > it must be recognized that managing the namespace and infrastructure
> > is a costly enterprise that may not be appropriate or cost effective
> > in a given business context.
>
> Second, note that all the extant legacy identifiers become immediately
> usable with this system. No requirement to construct dereferenceable
> URIs, machine/human readable metadata, etc.
>
> Third, and a even more practical concern for PubSubj, can we walk away
> from identifiers that comprise 2.6% of Google space?
>
> Having argued against dereferenceable identifiers early in this process
> I can hardly be considered neutral but I do think this proposal has much
> to recommend itself.
>
> I would suggest that we all spend some time with the full proposal as I
> think it may influence what we determine to be our next deliverables.
>
> Note that I am not arguing that network accessible human/machine
> readable metadata is a bad thing. It would be very useful to users and
> machines alike but useful does not equal required. As noted in the
> proposal we are discussing, publishers are free to do that, just not as
> part of that particular identifier.
>
> Hope you are having a great day!
>
> Patrick
>
> --
> Patrick Durusau
> Director of Research and Development
> Society of Biblical Literature
> Patrick.Durusau@sbl-site.org
> Chair, V1 - Text Processing: Office and Publishing Systems Interface
> Co-Editor, ISO 13250, Topic Maps -- Reference Model
>
> Topic Maps: Human, not artificial, intelligence at work!
>
>




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