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

Consider use of adms:identifier instead of prof:token #453

Open
nicholascar opened this Issue Oct 8, 2018 · 20 comments

Comments

@nicholascar
Copy link
Contributor

nicholascar commented Oct 8, 2018

No description provided.

@nicholascar nicholascar self-assigned this Oct 8, 2018

@nicholascar nicholascar changed the title Consider use of adms:identifier instead of token Consider use of adms:identifier instead of prof:token Oct 8, 2018

@makxdekkers

This comment has been minimized.

Copy link
Contributor

makxdekkers commented Oct 8, 2018

@nicholascar Can you provide a description for the issue?

@nicholascar

This comment has been minimized.

Copy link
Contributor Author

nicholascar commented Oct 8, 2018

Sure: we have a real need for non-URI identifiers for profiles when we need to referee to them where URIs are unsuitable, say in Query String Args in an HTTP API. We have, till now, presented a token property for the Profile class pointing to an xsd:token object for this but couldn’t we just use an adms:identifier instead? We can then fully implement adms:Isentifier instances with format strong etc. if required.

@andrea-perego

This comment has been minimized.

Copy link
Contributor

andrea-perego commented Jan 8, 2019

@nicholascar , I also was unsure about the purpose of prof:token, when profiles are supposed to have URIs. Now I better understand the point.

However, it is still unclear to me how this token will be defined: will it be a global identifier (and, in such a case, how this can be ensured?), or it will be rather specific to the service / API? In the latter case, I don't see how the token can be associated with the profile without avoiding possible collisions.

@agreiner

This comment has been minimized.

Copy link
Contributor

agreiner commented Jan 8, 2019

A URI can be used in a query string by urlencoding or something like base64 encoding. Maybe that's all one would need for a token.

@andrea-perego

This comment has been minimized.

Copy link
Contributor

andrea-perego commented Jan 8, 2019

@agreiner said:

A URI can be used in a query string by urlencoding or something like base64 encoding. Maybe that's all one would need for a token.

+1

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

rob-metalinkage commented Jan 8, 2019

A lot of existing systems have a compatible concept of profiles using a "server scoped" profile token - eg one of the W3C publishing process helper services takes an argument profile=FPWD which determines how it renders the content...

So the token allows us to retrofit URI identifiers to either locally or globally scoped profile identification tokens and generate a canonical metadata graph for these profiles already in the wild. And use of tokens is still likely to be preferable when using URLs instead of headers to navigate using alternative profiles.

@nicholascar

This comment has been minimized.

Copy link
Contributor Author

nicholascar commented Jan 8, 2019

Tokens for identifying profiles are seen in use in APIs such as Epimorphic's ELDA and CSIRO's pyLDAPI, e.g.:

So in the first case, the profile (view) token used is 'alternates', in the second its 'dcat'. There may be no URI equivalent for the first (it's listing of available profiles and, unless defined with a standard, may be replaced with mechanics specified in Profiles Conneg) clearly however the second use, of dcat, is equivalent to profile identification via DCAT namespace URI.

Yes, it would be an option to URL encode the DCAT namespace URI yielding http://linked.data.gov.au/dataset/gnaf?_view=http%3A%2F%2Fwww.w3.org%2Fns%2Fdcat%23&_format=text/turtle but this is ugly and long so we've not been using any forms of URIs for tokens.

All we are really dealing with is the equivalent of @prefix dcat: <http://www.w3.org/ns/dcat#> for convenience of use. PROF currently provides for this - you don't have to use it if you don't want to! - so Issue's question is whether adms:identifier can describe identifiers like this, rather than PROF's toke property.

@agreiner

This comment has been minimized.

Copy link
Contributor

agreiner commented Jan 9, 2019

My concern with this is that people may use the token as a unique identifier, but there is no registry to ensure uniqueness, and if we are to consider the use of whatever already existing tokens people have used for a thing they call a profile, uniqueness is already lost. Why include it in a standard then?

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

rob-metalinkage commented Jan 9, 2019

@nicholascar

This comment has been minimized.

Copy link
Contributor Author

nicholascar commented Jan 9, 2019

Why include it in a standard then?

Because they are both already in use and are needed going forward. We exclude a series of profile access API styles if we don't include tokens (RESTful APIs) and if we don't define rules, we'll just have the wild West of implementations.

Many Semantic Web data models, predicated on URIs, have provision for alternate, local, non-authoritative identifiers, like DC, ADMS etc. This argument's just run recently in DCAT land too. Best position seems to be to define alternate identifier mechanics.

If this ontology's used at all then users will necessarily be in URI land. the catering for non-URI IDs will make some mechanics simpler and broader modelling of existing profiles simpler.

@andrea-perego

This comment has been minimized.

Copy link
Contributor

andrea-perego commented Jan 9, 2019

@nicholascar , @rob-metalinkage , I still don't understand how tokens of this type (i.e., namespace prefixes), can be used as global identifiers, and not as something that is relative to the service / API.

I can buy a usage scenario where (a) I ask a service to list the available profiles, (b) I get the list of URIs and corresponding tokens/prefixes, and (c) I make a query using the token mapping to a given profile URI. But in this case the token cannot be included in the definition of a profile, as it may vary from service to service.

BTW, I would not bank at all on the fact that we have de facto standard namespace prefixes. One example is dc: / dct: / dcterms: which are all used for http://purl.org/dc/terms/ (where dc: is also used for http://purl.org/dc/elements/1.1/). And another one is the use of vcard: and vcard2006: for http://www.w3.org/2006/vcard/ns# (where vcard: is also used for http://www.w3.org/2001/vcard-rdf/3.0#). And finally geo:, used for GeoSPARQL, although it was already widely used for the W3C Basic Geo vocabulary.

@kcoyle

This comment has been minimized.

Copy link
Contributor

kcoyle commented Jan 9, 2019

APIs are a private case of negotiation; conneg is defining a public case. I agree with @agreiner and @andrea-perego that using anything but an actual URI as an identifier in "web space" is going to break "web things".

@aisaac

This comment has been minimized.

Copy link
Contributor

aisaac commented Jan 9, 2019

Could it be that the side discussion on namespace prefixes abbreviations gives a hint on how to handle the case of token?
Standardizing abbreviations seems like an ill attempt because in a local context (and abbreviations are always locally (re-)declared) one may use any abbreviation for a given namespace and things would still work. However there is some value in trying to homogeneize the use of abbreviations (at least it does sound like a best practice), and in our related work that's what been attempted with properties like http://vocab.org/vann/#preferredNamespacePrefix

@nicholascar

This comment has been minimized.

Copy link
Contributor Author

nicholascar commented Jan 10, 2019

@andrea-perego & @aisaac: I think I agree that local context identifiers, like in an API, don't need global representation.

@rob-metalinkage: can you indicate requirements for a profile to have a token listed globally in a PROF RDF write-up of one, thus requiring a prof:token as opposed to a local scope token only?

@nicholascar

This comment has been minimized.

Copy link
Contributor Author

nicholascar commented Jan 29, 2019

@aisaac I've added a PROF- > VANN suggested mapping to https://github.com/w3c/dxwg/wiki/PROF-Alignments-and-crosswalks

This certainly seems to be the most direct, currently used, equivalent to hasToken.

@nicholascar nicholascar modified the milestones: PROF 2PWD, PROF 3PWD Jan 29, 2019

@aisaac

This comment has been minimized.

Copy link
Contributor

aisaac commented Jan 29, 2019

@nicholascar thanks for putting a placeholder to it. I guess the answer to the question on which relation should hold between the two properties will depend on the answers from @rob-metalinkage

@andrea-perego

This comment has been minimized.

Copy link
Contributor

andrea-perego commented Mar 5, 2019

@nicholascar , @rob-metalinkage , I think the fact that this is a "preferred" token should be clarified in the property definition itself. Otherwise, readers will discover it only if they check the mapping with VANN - and they may be also confused, because of the current the definition of prof:hasToken - quoting:

A property for identifying this Profile for use in APIs

I would therefore suggest what follows:

  • Revise the definition of prof:hasToken with something like:

    The preferred token for identifying a Profile, alternatively to its URI

  • Revise the usage note, e.g., with

    This property indicates the preferred token that identifies a Profile whenever the Profile's URI cannot be used. For potential use in content negotiation.

    BTW, I think the usage note should be expanded, to offer further clarification, possibly with an example. As it is, it is not completely clear what it is about.

  • Consider making it explicit in the property name that this is the "preferred" token. Something like prof:hasPreferredToken

  • Consider also adding in the table with the property definition the relationship with vann:preferredNamespacePrefix

@makxdekkers makxdekkers closed this Mar 5, 2019

Profiles Ontology automation moved this from To do to Done Mar 5, 2019

@makxdekkers

This comment has been minimized.

Copy link
Contributor

makxdekkers commented Mar 6, 2019

I am not sure how I closed the issue. It was certainly not my intention, and I can't even remember that I did this. I must have clicked the wrong button.
By the way, I sent a message to the list (https://lists.w3.org/Archives/Public/public-dxwg-comments/2019Feb/0007.html), with a suggestion for definition and usage note:

Definition: “An alternative identifier for the Profile”
Usage Note: “To be used when the Profile’s URI cannot be used, for example in APIs or in content negotiation.”

@andrea-perego

This comment has been minimized.

Copy link
Contributor

andrea-perego commented Mar 6, 2019

Just re-opening it.

@andrea-perego andrea-perego reopened this Mar 6, 2019

Profiles Ontology automation moved this from Done to In progress Mar 6, 2019

@andrea-perego

This comment has been minimized.

Copy link
Contributor

andrea-perego commented Mar 6, 2019

@makxdekkers proposed:

Definition: “An alternative identifier for the Profile”
Usage Note: “To be used when the Profile’s URI cannot be used, for example in APIs or in content negotiation.”

I'm happy with the proposal, but, as I said earlier in this thread, it is important to make it very clear in the definition and usage note (and also in the property name) that this is the "preferred" token/identifier to be used - in analogy with vann:preferredNamespacePrefix.

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.