Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vann:usageNote used incorrectly in DCAT RDF representation #233

Closed
dr-shorthair opened this issue May 9, 2018 · 16 comments

Comments

7 participants
@dr-shorthair
Copy link
Contributor

commented May 9, 2018

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

@dr-shorthair dr-shorthair added this to To do in DCAT revision via automation May 9, 2018

@larsgsvensson

This comment has been minimized.

Copy link
Contributor

commented May 9, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented May 15, 2018

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

This comment has been minimized.

Copy link
Contributor

commented May 15, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented May 15, 2018

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

This comment has been minimized.

Copy link

commented May 15, 2018

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

@dr-shorthair

This comment has been minimized.

Copy link
Contributor Author

commented May 15, 2018

@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

This comment has been minimized.

Copy link
Contributor Author

commented May 15, 2018

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

@dr-shorthair

This comment has been minimized.

Copy link
Contributor Author

commented May 17, 2018

See #236

@VladimirAlexiev

This comment has been minimized.

Copy link

commented May 29, 2018

@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

This comment has been minimized.

Copy link
Contributor

commented May 29, 2018

@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

This comment has been minimized.

Copy link

commented May 29, 2018

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

@makxdekkers

This comment has been minimized.

Copy link
Contributor

commented May 29, 2018

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

@akuckartz

This comment has been minimized.

Copy link

commented May 29, 2018

@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

This comment has been minimized.

Copy link

commented May 30, 2018

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

This comment has been minimized.

Copy link
Contributor

commented May 31, 2018

@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

This comment has been minimized.

Copy link
Member

commented Jun 5, 2018

Change implemented in #236

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.