 |
 |
O.Stephens wrote: >> True. How, from the OpenURL, are you going to know that the rft is meant >> to represent a website? >> > I guess that was part of my question. But no one has suggested defining a new metadata profile for websites (which I probably would avoid tbh). DC doesn't seem to offer a nice way of doing this (that is saying 'this is a website'), although there are perhaps some bits and pieces (format, type) that could be used to give some indication (but I suspect not unambiguously) > > Yeah, I don't think there IS any good way to do this. Well, wait, okay, you could use a DC metadata package, and try to convey "web site" in dc.type. The OpenURL dc.type is _recommended_ that you use a term from the DCTerms Type vocabulary, but that only lets you say something like it's an "InteractiveResource" or "Text" or "Software". Unless "InteractiveResource" is sufficient to convey what you need, you could disregard the suggestion (not requirement) that the openurl dc metadata schema "type" element contain a DCMI Type vocabulary term, and just put something else there. "Website". If you want to go this route, probably make a URI (perhaps using purl.org) to put an actual URI instead of a string literal there to represent "Website". Now, you've still wound up with something that is somewhat local/custom, that other resolvers are not going to understand. But frankly, I think anything you're going to wind up with is something that you aren't going to be able to trust arbitrary resolvers in the wild to do anything in particular with. Which may not be a requirement for you anyway. (Which is why I personally find a new OpenURL metadata format to be a complete non-starter. I don't think OpenURL's "abstract" core actually provides much actual practical benefit, a new metadata format might as well be an entirely new standard -- for the practical benefit you get from it. Other link resolvers that aren't yours are unlikely to ever do anything with your new format, and if they do, whoever implements that is going to have almost as much work to do as if it hadn't been OpenURL at all. If I wanted a really abstract metadata framework to create a new profile/schema on top of, I'd choose DCMI, not OpenURL. DCMI is also so abstract that it doesn't make sense to just say "My app can take DCMI" (just like it doens't make any sense to say "my app can take OpenURL"--it's all about the profiels/schemas). But at least DCMI is a lot more flexible, and still has an active body of people working on maintaining and developing and adopting it.) Jonathan