Dxwg: vann:usageNote used incorrectly in DCAT RDF representation

[dr-shorthair]

The DCAT RDF representation has a lot of documentation captured as text in vann:usageNote elements.
This is incorrect, as it is a sub-property of rdfs:seeAlso - see http://vocab.org/vann/#usageNote.
rdfs:seeAlso is an owl:ObjectProperty so cannot have a Literal value.

Also, the VANN vocabulary is no longer available in RDF (I can't find it anyway).

Proposal: replace vann:usageNote with skos:scopeNote throughout

In the RDF representation of SKOS the definition of scopeNote is "A note that helps to clarify the meaning and/or the use of a concept."

[larsgsvensson]

Also, the VANN vocabulary is no longer available in RDF (I can't find it anyway).

vann is still around but has moved to a new server that isn't properly configured. That's at least what Ian Davies told me a while ago.

[dr-shorthair]

Regardless of whether VANN is available, usageNote is not an annotation property, so the current RDF is incorrect. Any objection to me changing all uses to skos:scopeNote ?

[kcoyle]

That looks like the correct substitution. SKOS doesn't give a good definition of scopeNote but I found one here: http://taxodiary.com/2013/10/scope-notes-and-editorial-notes/ that supports this usage.

[dr-shorthair]

In http://www.w3.org/TR/skos-reference/skos.rdf line 244 the definition is
_A note that helps to clarify the meaning and/or the use of a concept._

[akuckartz]

Both literals and resources seem to be allowed as values of skos:scopeNote. I really dislike that.

[dr-shorthair]

@akuckartz I don't think so: skos:scopeNote is an owl:AnnotationProperty (along with all the other SKOS notes)
https://www.w3.org/TR/skos-reference/#L1738

[dr-shorthair]

Whoops - you are right - the example immediately below the definition shows both - sorry.
I overlooked that AnnotationProperty != literal

[dr-shorthair]

See https://github.com/w3c/dxwg/pull/236

[VladimirAlexiev]

@akuckartz what's wrong with using a property that can take either resource or literal as value? All of DC and Schema are like that, since that is the variety-tolerant Open World way.

[makxdekkers]

@VladimirAlexiev Just a correction: not all of DC is like that. Yes, the properties in the /elements/1.1/ namespace http://dublincore.org/documents/dcmi-terms/#section-3, but definitely not the properties in the /terms/ namespace http://dublincore.org/documents/dcmi-terms/#section-2.
The problem with mixing resources and literals is that it is easy for data providers but more difficult for data consumers who need to be prepared to do conditional processing -- using the literal value, e.g. for indexing, in one case, or resolving the URI in the other case. It also makes validation more complicated.

[akuckartz]

@VladimirAlexiev How do you decide if something looking like a URL is a resource or a literal ?

[makxdekkers]

@akuckartz I guess the consuming application would just assume that someting that looks like a URL is a resource.

[akuckartz]

@makxdekkers Sure, there are heuristics which can be applied - and schema.org requires them. I am well aware of that approach. I prefer clean data which does not require heuristics. (But I also prefer grammatically correct HTML instead of legal but ugly tag soup)

[VladimirAlexiev]

By dc I meant DC Elements; dct (DC Terms) uses mostly object properties (and introduces some duplication, eg dct:date is just the same as dc:date). And shows good amounts of ontological over-commitment, eg it's a good idea to use dct:language to hold a language URL, but very few if any language resources in the world use type dct:LinguisticSystem.

@makxdekkers, @akuckartz any valid RDF representation certainly has explicit features showing whether something is a URL or literal, so no guessing is needed.
If you interpret your RDF data according to declared property ranges, you're doing it wrong.
In RDF XML and Turtle that's part of the syntax, in JSONLD you got '@type':'@id' (which is often put in a context).

Sem web being Open World must necessarily be tolerant towards data providers. schema.org is like this (pretty much all props take object or Text), but its context makes some over-commitments.

[makxdekkers]

@VladimirAlexiev I don't think that SemWeb should be tolerant to data providers. I think Postel's law would apply: be conservative in what you do, be liberal in what you accept from others. Moving the burden to the consumer seems to be the wrong approach.

I agree that data providers might be reluctant to provide data at all, and therefore relaxing the rules may help getting more content -- but if the content is inconsistent, there might not be much sense in the whole idea of the SemWeb.

[agbeltran]

Change implemented in https://github.com/w3c/dxwg/pull/236