HydraCG/Specifications

Stop advocating the use of the unmaintained and not dereferencable VOID vocabulary?

mielvds opened this issue · 8 comments

mielvds commented

This issue was opened after na internal discussion we had between @RubenVerborgh @pietercolpaert and myself. I will copy the jist here:

Pieter Colpaert
Instead of using void:subset, how about we start using dcterms:isPartOf? I’m working on a new hydra:search form that will also need to link the smaller part to its dataset description. Thought it would make sense to just use dcterms as we should deprecate void due to unmaintained and not dereferencable.
The entire set-up of void was way too messy anyway. I think we should use the hydra vocabulary for describing hypermedia forms, and DCAT-AP to describe the general concept of a dataset. I don’t think VoID has any role to play any longer. I’d rather advocate DCAT-AP to extend their predicates to also e.g., contain an approximate count of triples in a distribution of a dataset

Miel Vander Sande
Is void temporarily offline or is this somehow connected to the SemWeb intrest group closing down?
DCAT is too shallow and with reason.
So with the IG closed, you could say it's unmaintained.
At least with the dissapearance of void, we'd need a new way to describe Linked Datasets. And maybe an LDF vocab can take things to a more abstract level of "Fragments" to describe any response by any (HTTP) service. a new vocabulary for Linked Datasets that works in good collaboration with DCAT-AP, and maybe that could even become the Linked Data Fragments vocabulary (ldf:)

Ruben Verborgh
note the Data Exchange Working Group (DXWG) within W3C, who work on DCAT.
The reasoning is that the predicate should no longer be used because VOID doesn't dereference and is unmaintained.
unmaintained I don't think is a problem, since RDF Schema has been for over 10 years
it's stable, that's a feature, not a bug
doesn't dereference, I don't like that, but at least the URI has its semantics
these are just two counterarguments in hope of finding more arguments
that said, the ship has sailed and dropping void:subsetOf is likely not gonna happen for backward compatibility
we might want to use another property for the future
but we'll need to keep the old one around, probably indefinitely
However, is dcterms alternative set in stone?
because we'd at least need to see the alternatives or the full discussion to understand
TPF might change, but then TPF needs to be part of the discussion

To conclude: Should we replace void:subset in search forms and by what?

pietercolpaert commented

Regarding void:subset

I find this the most important one as it swill be relied on in multiple other specification as well that follow the TPF example.

I believe dcterms:hasPart has the same semantics and I would be in favor of that alternative. Above all, DCTerms is a well adopted vocabulary.

Regarding void:triples

void:triples indicates an approximate count of the number of triples. Not sure what to use instead... Maybe our own LDF vocabulary?

I find this one less urgent, as it is very TPF specific.

Other URIs used in the ldf-server, but not in the spec

What should change today

Proposed action: support dcterms:partOf in the spec, tell a client to look for both void:subset (deprecated) and dcterms:partOf

RubenVerborgh commented

Mmm, so given no alternative to void:triples, we are still stuck with void. I wouldn't feel comfortable with creating a vocabulary for only one property.

Given the software that exists and the number of years the draft specs have been around, we will also be stuck with having void:subset in clients and servers for the years to come.

So for me, the question is should we additionally add dcterms:partOf to TPFs?
While I am all for that given the above argumentation, I see some issues too:

  • Do we make dcterms:partOf a MUST and void:subset a SHOULD for servers?
    • If yes, then this means that all existing TPF servers are non-compliant from one day to the next. (So maybe we want a transition period.)
    • If no, then what do we do?
  • I assume that clients first look for dcterms:partOf and then for void:subset? That precedence is important since they—technically–could be different.

As an aside, a question I've never fully found an answer to myself: is dcterms really the final one? Because there's also two versions of dc: http://purl.org/dc/elements/1.1/, http://purl.org/dc/elements/1.0/.

pietercolpaert commented

As an aside, a question I've never fully found an answer to myself: is dcterms really the final one? Because there's also two versions of dc: http://purl.org/dc/elements/1.1/, http://purl.org/dc/elements/1.0/.

In the Linked Data world I see a convergence to the use of the more extensive dcterms over all other versions.

pietercolpaert commented

Apparently VOID is back online: http://vocab.deri.ie/void

  • 🎉1
tpluscode commented

Apparently VOID is back online

Do you think we can close that then @pietercolpaert?

  • 👍2
pietercolpaert commented

Yes, sure :)

alien-mcl commented

I find no clues of VOID in the hydra core vocabular, thus I believe it is OK to close that issue. Feel free to reopen it if needed.

BTW. Void seems to be down again :/