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

How should we handle links from an asset to its online access point(s)? #2

Open
jeff-zucker opened this issue Nov 26, 2024 · 0 comments

Comments

@jeff-zucker
Copy link
Member

jeff-zucker commented Nov 26, 2024

How should we handle links from an asset to its online access point(s)?

When an Asset is available in two versions which are identical other than format, the are considered in ADMS as instances of dcat:Distribution which can specify a URL and metadata about the URL like its IANA media-type.

:SomeDocument
  a adms:Asset ;
  dcat:distribution
    [ dcat:mediaType "text/html"; dcat:downloadURL <..> ],
    [ dcat:mediaType "application/pdf"; dcat:downloadURL <..> ],

For Assets which have a single version, the dcat:accessURL is available. But its object is a simple URLs which would not allow us to differntiate between different kinds of URLs. For example a mailing list accessURL might be a subscription link or an archive link; a software might have different links to code, the dataset used, or a webapp running the code. And none of those things depend on media type. Further, they do not necessarily represent versions of an identical thing in a different format so can't really be considered dcat:Distributions.

So there is no current term in ADMS/DCAT that I know of that would handle multiple typed links for an asset where the links do not point to different versions of the same thing like a distribution. I propose we use typed links where the types are stored in the concept scheme. Something like this:

@prefx t: <./solid-skos-concept-scheme.ttl> .

:CG_Mailinglist vcard:url
  [ dct:type t:Subscription ;   vcard:value <...>; ] ,
  [ dct:type t:Archive ;        vcard:value <...> ].

:Solid_Catalog vcard:url
  [ dct:type t:Webapp ;         vcard:value <...>; ] ,
  [ dct:type t:Dataset ;        vcard:value <...>; ] ,
  [ dct:type t:CodeRepository ; vcard:value <...> ].

This is similar to the solution which SolidOS uses by adding 'WebId' to the vcard ontology so that we can say things like

:me vcard:url [dct:type vcard:WebId; vcard:value :me].

However, by allowing the object to be a SKOS concept rather than a class in an external ontology, we stay in sync with the skos structure used to type assets and we can create the types in a structured way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant