Unique temporary identifiers

[elf-pavlik]

Many entries may not have canonical stable URIs at the beginning (for example WebIDs).
Current forms presented by @jeff-zucker create fragment identifiers in a way that could collide (while very unlikely).
Since those are only temporary identifiers that are being created inside of catalog dataset, we could use urn:uuid: which is easy to generate in web browsers with crypto.randomUUID(). This URI scheme is defined in https://www.rfc-editor.org/rfc/rfc4122.html

[jeff-zucker]

This is a minor complaint about a major problem. Adding uuid's instead of handles made from the resource's name does not really fix the real problem which is that we want the subjects of the triples to be URLs outside of the catalog if possible. As I see it the subject should be (in this order depending on what's available) : clientID, webID, serviceEndpoint, landingPage, uuid. So we need a script (which does not need to be tied to the forms) which can go through the kb and check to see if the subject is one of those and if not, make it one of those and then cycle through all objects which match the original name and change those objects to the new name (e.g. if #foo is provider we change :Bar :provider :Foo to :Bar :provider <http://foo.example.com/card#me> throughout the kb. We will need to do this for all existing records, not just new records (e.g. someone adds a webid later). So someone should volunteer to write a stand-alone script to do that which we can run periodically separate from the input forms.

[elf-pavlik]

I assume that you refer to the catalog dataset as kb.

As an example in this shape

catalog/v2/catalog-shacl.ttl

Lines 303 to 308 in 3dca072

	sh:property [
	sh:path ex:webid ;
	sh:description "your WebID" ;
	sh:datatype xsd:string ;
	sh:maxCount 1
	] ;

I don't think we should have webid as property but use it as an identifier of the Person. If it is not provided we would generate a temporary one which I propose to be simply urn:uuid:

Forms could always have id field which would be used to denote the thing so appear as subject/object in statements describing it. An additional hint could suggest that for People and Organizations it is WebID, for Applications ClientID and URL denoting it for the rest.

A script which you suggest sounds to me like a migration script, where in v2 we use property like webid and in v3 we remove it and use the WebID to directly identify the agent (similar with ClientID etc.).

A separate script would be responsible for replacing a temporary identifier, urn:uuid: in my proposal, with canonical URL whenever it becomes available. This should be pretty straight forward, simply finding all he statements with given temporary identifier as either subject or object and replacing it with the new cannonical URL. After that the temporary identifier could either disappear or we could include statement in lines of <urn:uuid:xxxx> schema:supersededBy <newCanonicalURL>.

[jeff-zucker]

I assume that you refer to the catalog dataset as kb.

yes - knowledge base

I don't think we should have webid as property but use it as an identifier of the Person. If it is not provided we would generate a temporary one which I propose to be simply urn:uuid:

I disagree, viewers of the record will want to be able to see the WebID.

Forms could always have id field which would be used to denote the thing

This seems like an unnecessary step.

An additional hint could suggest that for People and Organizations it is WebID, for Applications ClientID and URL denoting it for the rest.

That a) sounds confusing for input and, more importantly b) would leave no way for us to tell what the identifier was. If it's a clientID, I want to know that, if it's a landingPage, I want to know that. How would we display those back to the viewer without knowing which of them was used for the subject identifier. I am in favor of using whichever is present AND displaying it as a field.

A script which you suggest sounds to me like a migration script, where in v2

No, it isn't simply migration, it will need to be run periodically on all data.

A separate script would be responsible for replacing a temporary identifier, urn:uuid: in my proposal, with canonical URL whenever it becomes available. This should be pretty straight forward, simply finding all he statements with given temporary identifier as either subject or object and replacing it with the new cannonical URL.

Yes, it's that easy but it would be the exact same thing as replacing the current subject identifiers with a WebID or other value and I don't see the value in maintaining two scripts.

After that the temporary identifier could either disappear or we could include statement in lines of <urn:uuid:xxxx> schema:supersededBy <newCanonicalURL>.

Right.

[elf-pavlik]

I added some links in #58 before preparing another PR I need to be able to create new records.
Before doing that I would like us to agree on a JS function which will generate temporary identifiers.

I would propose

const genId = (): string => `urn:uuid:${crypto.randomUUID()`

Any other suggestions?

[jeff-zucker]

Looks okay to me. This is for new records for now but later we will convert existing records?

[elf-pavlik]

Yes, I just need to add some missing records. Changing temporary ids of existing records should also be pretty simple, if you like I could assign to myself writing a script that can do it.

[jeff-zucker]

I am fine with you working on a script to make these changes as long as they only use the ex:webid field to create an ID and do not remove the existing webid field. To do that would require lots of work on the scripts and so should be left until we have an LDO version and even then, I am in favor of leaving them in. It is a field in the SolidOS Person shape.

[elf-pavlik]

I can think of a siplification

• remove - from UUID after generating it to have simpler way of jumping between occurences if manual edit is needed

We should also pay attention to all the existing IRIs in cdata: namespace when we work on something like #52
In the future there might be permanent identifiers in cdata: namespace and before intoducing them we should make sure to clearly separate all existing temporary ones. Otherwise it will require more complicated queries to tell the difference.