>> 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.)