Beyond Seamless Access: Meta-data In The Age of Content Integration
•Transferir como PPT, PDF•
1 gostou•1,178 visualizações
This was an example of meta-data research that I did before Dot-COM bubble hit the East Coast in 2000. Much of what we envisioned for content integration shaped the meta-data movement for today. Its full potentials have not reached yet, e.g. the level of intelligent data for semantic apps, personalized delivery, interactive and bidirectional-linking services, repurposed services, etc. It's the first of its kind weaving content from scholarly publications (particularly in the context of formal and informal communications) with library mission critical applications in authority control, meta-data, directory services, ILS, ILL, knowledge-base for site map, etc.
![OVERVIEW ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (7)
Semelhante a Beyond Seamless Access: Meta-data In The Age of Content Integration
Semelhante a Beyond Seamless Access: Meta-data In The Age of Content Integration (20)
Último
Último (20)
Beyond Seamless Access: Meta-data In The Age of Content Integration
- 1. Beyond Seamless Access: Meta-data in the Age of Content Integration Spring 2000 Program Information Technology Interest Group of Association of College & Research Libraries, New England Chapter Univ. of Connecticut May 26, 2000 Amanda Xu Information Architect EBSCO, 10 Estes Street, Ipswich, MA 01938 axu@epnet.com
- 17. Definitions (3) Linking Structures [5/6] Query Category map filter profiles knowledge domains languages access rights delivery views/devices DB Structured docs Unstructured docs Link Cluster Adaptive categories Attach categories Match query Result set w/ category map Search/ navigate TOPIC MAP Leverage Topic Maps TOPIC MAP TOPIC MAP TOPIC MAP TOPIC MAP TOPIC MAP 1 2
- 26. Questions?
Notas do Editor
- When you provide meta-data for the data, you might record when when was the data created? By whom?, how long is it valid? You may want to serve up the metadata document first, so people that interact with your web site can first decide if the data is relevant before actually downloading the data You might provide hyperlinking capabilities in your data so that you can express the relationship between this data and other data
- &quot;Eve L. Maler&quot; <elm@ARBORTEXT.COM> XLink is needed, first of all, because in an XML document you can use whatever element names you want. In HTML, it's predetermined that A and IMG (and a couple of others) do link-ish things, but software can't predict ahead of time what the linking elements will be called in an XML document: FOOTNOTE? ANNOTATION? RELATIONSHIP? CROSS-REFERENCE? So you have to put a &quot;marker&quot; (in the form of a special attribute) on your element in order for XLink-aware applications to recognize it. In addition to this innovation, however, XLink does another important job, which is invent a whole new form of link. In HTML, A is a two-ended, unidirectional link: you click from here to go there. In XML, this would be a &quot;simple link,&quot; but you can also have a 318-ended &quot;extended link&quot; where you can start from any one of the ends and go to any of the others. And on top of this, the link doesn't have to be stuck into *any one* of those 318 pieces of content! This means that you can store the linking information outside all the information that you're hooking together, so you can update your link if one of the 318 chunks changes in any way. Here's an example of a plain vanilla (&quot;simple&quot;) XLink linking element that functions just like an HTML A element (using syntactic details from the 19980303 working draft; this is highly likely to change a bit in the next draft). In fact, this example is actually an XMLified HTML fragment: See <a xml:link=&quot;simple&quot; href=&quot;http://www.arbortext.com&quot;>our home page</a> for more cool information. Now, on to XPointer. If you use HTML's A to point into an HTML document, your choices are: Point to a whole HTML page Point to a &quot;spot&quot; somewhere inside the HTML page, using # Often, it's useful to point to some actual content, instead of a &quot;spot.&quot; For example, you might want to direct your readers' attention to the third item in a particular list, or a certain stretch of text in the equivalent of a PRE element. When the content of interest is in an XML document, then you can rely on XML's natural tree structure to provide signposts that you can use in navigating to the right stuff. XPointer is a little mini-language that you can stick on the end of a URL after the #, in the case where the URL points to an XML document. It uses a keyword-and-arguments syntax like this: keyword1(arg1,arg2).keyword2(arg1,arg2) For example, if you want to link to the third item in the list with a unique ID of &quot;interesting-list&quot;, you can do it this way: href=&quot;http://www.foo.com/bar.xml#id(interesting-list).child(3,item)&quot; There's a whole boatload of keywords, and some of their arguments can get a bit complicated, but that's the basic idea. The best part about XPointer is that, if you do addressing this way, your link will probably be more robust against some change in the target document. For example, even if the target list is cut and pasted somewhere else, the fact that it has a unique ID will keep your link operational. (Now, if someone rearranges the items, that's another story.)