Add extra properties to the vocab to make it easy to tell apart old ones from the current

[berezovskyi]

Problem: if we encourage users (as we should, see Linked Data Rule no. 3), they have no way of telling how old the vocabulary they are looking at is. The problem gets worse if they store it on disk.

Proposed solution: add some RDF properties, just like DCTerms does. See proposal in https://github.com/oslc-op/oslc-specs/pull/325.

Please note that I strongly disagree with placing information into URIs because URIs shall be opaque.

[berezovskyi]

Fun fact: I went looking for a tag predicate following a request from Jim on https://lov.linkeddata.es/dataset/lov/terms?q=tag&page=2 and I found a perfect property:

[jamsden]

Unfortunately users do have to look at URLs as they type them, understand the implications of http vs. https protocols, the server and port have to be known, and all fragment identifiers and query parameters of necessity include user provided information.

So I don't think we need to be purists here. It is not putting semantic information in URL paths that makes them opaque or not, it wether anything explicitly relies on knowing that information.

[berezovskyi]

The key point of opaqueness is to make it possible for machines to use LD, not for people. People have HTML for that. Metadata needs to be machine readable first.

[ndjc]

I'm not really sure why this issue is separate from issue 326: is it that #325 asks if extra properties are required at all - if they are the right solution, and #326 asks (presuming the response to #325 is Yes) what those extra properties should be? So if this issue were to be closed agreeing that extra properties are not required, then #326 would be closed as moot?

[ndjc]

I don't like the idea of maintaining any extra properties manually - that guarantees they'll be wrong sometime. If we really need to do this, we should also try to automate it as much as possible.

[berezovskyi]

One is an issue and another is a PR with an example? Ofc is the issue is closed as wontfix, PR gets scrapped.

Cheers, Andrew

---

From: Nick Crossley notifications@github.com Sent: Thursday, June 4, 2020 9:42 PM To: oslc-op/oslc-specs Cc: Andrew Berezovskyi; Author Subject: Re: [oslc-op/oslc-specs] Add extra properties to the vocab to make it easy to tell apart old ones from the current (#326)

I'm not really sure why this issue is separate from issue 326: is it that #325https://github.com/oslc-op/oslc-specs/pull/325 asks if extra properties are required at all - if they are the right solution, and #326https://github.com/oslc-op/oslc-specs/issues/326 asks (presuming the response to #325https://github.com/oslc-op/oslc-specs/pull/325 is Yes) what those extra properties should be? So if this issue were to be closed agreeing that extra properties are not required, then #326https://github.com/oslc-op/oslc-specs/issues/326 would be closed as moot?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/oslc-op/oslc-specs/issues/326#issuecomment-639075421, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAPZXSFPKAPBJA2SWSFFFDRU72J3ANCNFSM4NSZLRKQ.

[berezovskyi]

Just a reminder: you should suggest which properties to keep in #325.

[ndjc]

@berezovskyi have we not now fixed this by adding the extra properties on vocabularies and shapes (ResourceShapeConstraints)?

[ndjc]

@berezovskyi - see previous comment - can we not close this issue now? If we want further automation in the future, we should create a new issue to describe precisely what we intend.

[berezovskyi]

@ndjc I trust your judgement. In the future, feel free to close the issue with the comment "Please reopen if ..." for the sake of expediency.