Re: ACTION-83 Get clarification from Maxx Deckers on what DC meant in what they specified

On 27 Oct 2012, at 15:10, Makx Dekkers wrote:
> But isn't that what Linked Data is all about? You get the URI of a
> resource, then you follow your nose to find out what it is and what it
> says about itself.

But sometimes you're not interested in finding out more about the object. You just want to know, in the simplest and most convenient way, which from a possible set of values the object is.

For example, if I have a property that takes boolean values, it would be rather strange to expect URIs there. There are only two boolean values, and all my application will ever need to know about boolean values is already hardcoded in the programming language. Dereferencing a URI to find out which of the two boolean values it actually is would be colossal over-complication.

The same is true for numbers, for example. All that one needs to know to unambiguously identify a number can be easily written down into a literal, like so: 123. There's a reason why Linked Open Numbers — the dataset that assigns URIs to the natural numbers — was done as an april fools' joke [1].

> Wouldn't DCAT, by saying that it is more convenient to use a string to
> represent a real-world thing, effectively be saying that using URIs as
> references is *inconvenient*?

But URIs *are* inconvenient, compared to literals. See above.

The problem with literals is just that they are pretty useless for unambiguously identifying most things. I can't unambiguously identify a person, for example, with a literal, because there is no universal identifier scheme for people, and no well-defined datatype that I could slap on the literal that makes it actually clear how the literal refers to people.

But for languages we have the identifier scheme and we have the datatype, so why make it any more complicated than necessary?

> And on the specific issue of language: what are we telling the Library
> of Congress (and these others who build URI collections for languages)?

Presumably they do this because they want to organize additional information about these languages and their relationships. Defining URIs for the things that your information is about is of course a good idea, *because it is convenient*.

> Stop what you're doing because we have a "more convenient way" to do
> this?

In DCAT we need a way to refer to languages, not to record additional information about languages. The convenient way of doing the one may not be the convenient way of doing the other.

If ISO or IETF, as publishers of ISO 639 and BCP 47, would produce a URI scheme for languages, then I'd heartily recommend its use. Or even if W3C itself would be publishing one. Or, heck, even Dublin Core. But I don't think that W3C specifications should have dependencies that rely on a national library, or academic research projects, or enthusiastic hobbyists. Given that, the only viable options that I see are:

1. Leave it unspecified (a.k.a. kiss interoperability goodbye), or
2. Recommend that the best available thing defined by a standards organization be used: an xsd:language literal.

Best,
Richard


[1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.174.2568&rep=rep1&type=pdf


> 
> Makx.
> 
>

Received on Saturday, 27 October 2012 16:14:12 UTC