[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Next Steps?
Greetings! Well, XRI is out, at least in draft form. I won't comment on it here but suffice it to say if we want Published Subjects to gain some traction we need to move forward here so XMLVoc, and GeoLang can as well. Suggested outline for a specification: I. Introduction II. List requirements and recommendations (see note below on forcing URLs) III. Specify the details of the requirements and recommendations IV. Conclusion V. Boiler plate, etc. A little more on III: Requirement 1. Must be a URI, simply refer to the canonical document (RFC 2396). Not a lot we can add to that is there? Requirement 2. must resolve..., must use URL (RFC1738, relative URL 1808) Note can use URNs but not considered conforming PSIs for this specification. (I still think this is a serious and web-headed mistake. This requirement excludes all manner of things included by XRI, which despite their failure to read Pepper on web identity, at least avoids this mistake. People are going to want to use URNs and to exclude just makes PSIs less attractive, with no gain. Sorry, really think we need to fix this.) Requirement 3. explicitly state the unique URI OK: "The unique URI for this PSI is: (insert content)." Recommendations: 1, 2 and 3: Use unqualified Dublin Core metadata. Already in use by the OAI (Open Archives Initiative, http://www.openarchives.org). No point re-inventing the wheel. (for unqualified Dublin Core metadata, see: http://www.dublincore.org/documents/dces/) Note that it is by definition machine and human readable, and if you use the same metadata for both, by definition have meet #3. Recommendations 4 and 5, declaration that it is a PSI and its publisher. Publisher: Dublin Core metadata <creator> PSI Declaration: Dublin Core metadata <type>, which is defined as: "The nature or genre of the content of the resource." Thus, <type>Published Subject Indicator</type> Note that other than providing the specification, there should be NO tutorial or introductory material in the specification. That should be in a separate document that issues along with the specification. The separate document with examples/tutorials, etc., should show how to construct PSIs in a vaiety of ways, HTML page, HTML fragment, XTM, OAI (the latter is one I am particularly interested in, see the following.) OAI permits the construction of sets of metadata and I suspect that one could build a very robust set of PSIs using strictly the OAI schema. Note that OAI already has hosting and harvesting software available, which would make use of OAI compliant PSIs quite easy. OAI has a unique identifier element for each record (their terminology) so one could include the unique URI there. Comments on either the outline of the specification or perhaps even the OAI part of the tutorial material? (I am willing to volunteer to do at least a rough draft of both, perhaps more. I really think we need to move forward fairly quickly and am willing to devote time to that end. I might even be tempted into using IRC, but never having been in a chat room, no promises. ;-) ) Separate question: Given that XRI is allowing identifiers beyonds URLs, is there any support for revisiting the question of URLs? If not, that will lose a degree of support but I don't know how much. Actually since it was never specified what "published" means I suppose closed systems like Jim Mason's could "resolve" to a local file or server. Hope everyone is 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!