Add :url to BIBO

[kcoyle]

• Recommendation: add bibo:url property, similar to schema:url
  • domain: can be left open?
  • TAP: "URL where the electronic resource (e.g., a file) or a part of it can be retrieved."
  • profile: "This property SHOULD be used to provide the online download location for the resource."

[niklasl]

There is bibo:uri, which is a datatype property. Would that suffice, or is it too closely related to the resource itself (as identifying it)?

Schema's url is a bit vague (in the example it appears to be more indirect, as in the homepage of a person). It too (like bibo:uri) assigns a "literal URL" (as in a datatyped value, not a reference to the resource it denotes). Schema also defines associatedMedia (and a synonym encoding),. Somewhat confusingly, it also has downloadUrl, whose only suggested use is for software applications.

There are also the foaf:page (fairly close but not equal to what is needed here, IMHO), dct:relation (may be too wide/vague), and dct:hasFormat (somewhat different "sideways angle" of use). In BIFRAME, bf:electronicLocator seems to align with the purpose here (but brings with it a far richer context).

Note that I'm not suggesting to mix in these other properties and vocabularies (though some might be mapped). We may consider what is needed here in relation to those though (how they are defined), so that, given the requirements for this new property, it has a clear affordance of use (for consumers). Ideally, it might also help others avoid confusion which these variations of scope and purpose tend to bring about.

[kcoyle]

@niklasl I have similar thoughts about this. There is:

• URI (IRI) with emphasis on the "I" for identifier
• URI (IRI) as "landing page" (where you might still have to click on a link to download or retrieve the resource)
• URI (IRI) (URL) as direct locator of the described resource
• (I probably forgot some)

I doubt if we can or should create a property that makes this distinction, especially since many URIs are performing multiple functions. Yet I'm not sure a definition that includes all of these different meanings is going to result in useful metadata. We also have to think about what knowledge the cataloger has about the function behind a URI.

My gut feeling is that we have to leave it as ambiguous as it is in reality.

As for "literal URL"s, SRAP has defined the :url property as an IRI. I bet that those "literal URLs" get used as clickable in many systems. We had URLs in string data before the distinction of literal vs IRI, and I don't think they caused a problem.

[aisaac]

The definition from SRAP is "srap:url: This property SHOULD be used to provide the URL where the electronic resource (e.g., a file) or a part of it can be retrieved using a web browser. It can either be the document itself (e.g. a PDF file) or a landing page."
This definitely sounds rather like schema:downloadUrl. And it hints SRAP should not use (and make a clearer distinction with) bibo:uri because that one is rather for URIs as identifiers of the resource.
For the record DCAT has also a dcat:downloadUrl: https://www.w3.org/TR/vocab-dcat-3/#Property:distribution_download_url (and dcat:accessURL and dcat:landingPage )

[kcoyle]

I had forgotten about Jeni Tennison's excellent musing on URLs: https://www.jenitennison.com/2011/07/05/what-do-uris-mean-anyway.html

To me, the issue this brings up is that you can't know what a URI points to until you send a request for it. It's a mess.

I would prefer a less specific definition:

This property SHOULD be used to provide a link that directly accesses the resource being described or that facilitates access to the resource.

And I like the idea of :accessURL. That would make it clearer to those creating or using the metadata what this particular URL is for. I think this could fit into BIBO nicely.

[kcoyle]

A thought: is access always going to be a URL? I'm thinking of archives (not quite within SRAP boundaries) that have a phone number or address where you ask to have access. The argument against this is that SRAP intends this to be a direct or nearly direct link to the resource itself, so the broader meaning would make that less clear. Maybe ignore this comment ;-).

[tombaker]

+1 for bibo:accessURL.

[kcoyle]

I'd like to suggest "accessLink" which is broader than URL. Another possibility would be something along the lines of "accessPoint". I am concerned that "URL" is narrower than is intended.

[tombaker]

PROPOSED FOR STRAWMAN VOTE:

New term bibo:accessLink

Definition: "Link, such as a URL, where a digital resource can be retrieved, in whole or in part, using a Web browser.

[osma]

I don't quite understand how accessLink would be "broader than URL", if the definition states that it can be "retrieved [...] using a Web browser". What could such a link be that is not a URL but can be retrieved using a Web browser?

Personally, I'd prefer accessURL as in DCAT. FWIW, DCAT defines accessURL like this:

A URL of a resource that gives access to a distribution of the dataset. E.g. landing page, feed, SPARQL endpoint. Use for all cases except a simple download link, in which case downloadURL is preferred.

[niklasl]

Maybe just accessedAt or accessedFrom, to avoid requirements on the type of reference? (Unless a literal reference like a URL is the sole kind of object. I agree that URLs are what web browsers access.)