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.