search

w3c / dx-prof

The Profiles Vocabulary
https://w3c.github.io/dx-prof/prof/
Other
5 stars 2 forks source link

Replace prof:hasToken with dcterms:identifer #49

Open nicholascar opened 3 years ago

nicholascar commented 3 years ago

dcterms:identifier can act in all the ways we've specified prof:hasToken to act (same datatye pf xsd:token too) but we save the hassle of introducing a new property.

aisaac commented 3 years ago

dcterms:identifier doesn't have a datatype of xsd:token as far as I'm aware. My fear would be that in an open world one could give identifiers to a profile, which are not fit for your token use cases.

nicholascar commented 3 years ago

Good point. I guess I meant that dcterms:identifier doesn't have a datatype conflicting with xsd:token as, of course bieng DCT, it doesn't have a string indication of range type.

Something we are missing in PROF still is actually a useful validator file for PROF data - e.g. SHACL. If we made such a thing, it could perhaps check for use of dcterms:identifier with xsd:token.

I also think that it's relatively safe for us to describe the requirements for a PROF token and then expect people to "do the right thing" regarding how they create and use them since their use is anticipated within systems that actually operate, so that people would know quickly whether their dcterms:identifier value is any good (e.g. their system can't tolerate spaces and fails in some way).

aisaac commented 3 years ago

Yes this could be a right approach, but in the specific case of PROF I expect there might be legit cases where people would like to have other identifiers than the token (maybe a id derived from a standard body like ISO, or something else?). For validation I'm afraid you'd have to say that either the only type of (general) dcterms:identifier allowed is token, which is not flexible for the cases above, or allow several dcterms:identifiers (with different types) to co-exist, which would make validation with SHACL (or others) more difficult.

kcoyle commented 3 years ago

The prof:token definition excludes URIs as identifiers:

The preferred identifier for the Profile, for use in circumstances where its URI cannot be used.

dct:identifier prefers URIs but does not exclude string tokens. The two properties do seem to be different. To me it would make sense to use both, dct:identifier when one has a URI, and prof:token as a fall-back when no URI is available.

I am also wondering about the possible use of file://host/path scheme to indicate files on the same namespace. We are looking at this in the DC profile work, since we assume that many folks will have files on the same site or even in the same directory. It would be a stretch to call this a dct:identifier since it could be any kind of file - would it be considered a PROF:token?

dr-shorthair commented 3 years ago

Multiple identifiers can all use dcterms:identifier disambiguated with a datatype.

aisaac commented 3 years ago

That still wouldn't warranty that nobody isn't going to use the datatype you want for something else. xsd:token is not essentially related to a profile negotiation goal...