cygri / void

An RDF schema and associated documentation for expressing metadata about RDF datasets
http://www.w3.org/TR/void/
14 stars 1 forks source link

Use case: linksets to non-RDF targets #108

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
A use case mentioned on the list by Alasdair Gray.

They have linksets that don't link to another RDF dataset, but to a set of web 
pages. Example: Each gene might have an associated web page on some biomedical 
database site (which is exposed only as HTML).

Linksets currently assume that both "ends" of the link are RDF datasets. The 
assumption would have to be relaxed for void:Linkset to be appropriate here.

Original issue reported on code.google.com by richard....@gmail.com on 23 Mar 2013 at 8:15

GoogleCodeExporter commented 9 years ago
This is a very pressing use case within the Open PHACTS project. 

We have adopted VoID as our mechanism for describing our RDF datasets but have 
found that we need to provide links to, and descriptions of, non-RDF datasets. 
While we can describe non-RDF datasets using dctypes:Dataset or dcat:Dataset, 
we have not found an equivalent for void:Linkset and the void:linkPredicate and 
void:target predicates. 

A couple of alternative approaches:
* Relax the range on the existing void:linkPredicate and void:objectsTarget 
predicates
* Provide equivalent predicates to void:linkPredicate and void:objectsTarget 
that do not have the range restriction

Both of the above assume that the link is from an RDF dataset to a non-RDF 
dataset. We do not have a current use-case for this, but it is probably worth 
considering if it beyond the scope to consider links between two non-RDF 
datasets at the same time?

Original comment by alasdair...@gmail.com on 27 Mar 2013 at 9:09

GoogleCodeExporter commented 9 years ago
Seems like a reasonable use case for VoID to cover. Linksets should not require 
either the subjectTarget or objectTarget to be an RDF dataset - it makes sense 
for linksets to be able to link web pages and any URI-identified resources.

Ideally there would be something like a 'UriDataset' class to point the ranges 
at, but maybe it's simpler just to use something generic like dcmitype:Dataset.

I'm in favour of changing the existing predicate definitions (rather than 
create equivalent predicates), unless someone can see that it will break things 
for existing VoID consumers.

Original comment by K.J.W.Al...@gmail.com on 29 Mar 2013 at 6:47

GoogleCodeExporter commented 9 years ago
Has there been any progress on this issue?

Original comment by alasdair...@gmail.com on 17 Jun 2013 at 3:45

rob-metalinkage commented 9 years ago

Another angle on this - let us imagine a world where content-negotiation may be used to get the RDF, or HTML, or other representation of a resource. Would it be valid to use a Linkset in these cases whre RDF may be available at some point in the future? If not, then you'd need to develop a best practice for migrating or reconciling an alternative (lets call it a CrossRefSet for arguments sake) with a Linkset in the future when a RDF encoding is available for the given URIs.

Maybe this can be done using polymorphism - simply declare it a void:Linkset in addition to document that RDF is now available. Or, maybe you simply get explicit using TechnicalFeature and dcterms:hasFormat from the outset, and let the user decide how a Linkset can be exploited based on its technical features.