Re: "undefined" URI scheme

It sounds to me like all you need is a URI that doesn't resolve (but could at a later date if you wanted to add meaning to it).
If you have a domain access somewhere, then just make a random string on that domain - then you can make it resolve later if you want, and it is unlikely that someone else will use that URI for something unconnected.
If not, choose a domain (example.org would do) and do the same thing.
(This is the LOD list, so non-http(s) schemes are not allowed :-) )

If I trip over a non-resolvable URI, I think I interpret it exactly as you want - it is someThing that the publisher has some idea of what it is, but isn't going to tell me.
Mind you, I may infer some stuff, because in order to trip over it I must have found it has a relation with some other URI that you published...


> On 19 Nov 2018, at 12:48, Laura Morales <lauretas@mail.com> wrote:
> 
> Thanks for the comments. I think however that you guys are trying to add a meaning to this hypothetical <undefined:> schema or anyway classify it somehow, whereas the goal in my mind is simply like "yeah there is this property but it doesn't really have a well defined meaning unless you know what I'm talking about" and it shouldn't matter if it's reused over and over with different meaning. It's just there, do with it whatever you want. I understand that it's not ideal since all graphs should strive to reuse existing ontologies, but there are situations where you just need a URI and you are not in a position to worry about schemas. It can be used as a placeholder or a "to be defined later" property. If I use it on my graphs, other people should probably not rely on it unless they know what they are doing since it's likely to change at a later time. Theoretically speaking maybe it doesn't make much sense, but practically speaking it does.
> 
> - I could probably use <http://example.org/> instead, but ironically <undefined:> would provide more meaning than that, since the user knows not to expect too much from an <undefined:> property. As a thought experiment, if somebody let's say Eurupeana publishes a property <undefined:find-this-book-at> property I can guess that the property describes a place where to find the ?subject but I know that the property is likely to change in the future, maybe to be replaced by some other more appropriate e definitive property.
> 
> - I think "blank properties" would be useful for practical purposes, for example _:find-this-book-at, and for me they would be equivalent to <undefined:>. But rewriting the standard to include blank properties would be a much harder task than simply accepting a <undefined:> URI
> 
> - The SKOS example is also good <urn:uuid:0ef595e6-5d9f-469c-b351-8565a0b081dd> a skos:Concept, but it's less intuitive (in my opinion) and more cumbersome to work with. Unless maybe I can use <urn:uuid:find-this-book-at>?
> 
> 
> 
>  
>  
> 
> Sent: Monday, November 19, 2018 at 12:38 PM
> From: "Stian Soiland-Reyes" <soiland-reyes@manchester.ac.uk>
> To: "Laura Morales" <lauretas@mail.com>
> Cc: public-lod@w3.org
> Subject: Re: "undefined" URI scheme
> On Mon, 19 Nov 2018 11:55:30 +0100, Laura Morales <lauretas@mail.com> wrote:
>> Full original thread here: https://lists.w3.org/Archives/Public/uri/2018Nov/0000.html
>> 
>> Since I was asked to redirect my request to the "RDF community" I'm
>> posting here for comments, because I don't know if there is any
>> official place to ask to.
> 
> Hi,
> 
> I'll have to agree with Martin J. Dürst and Graham Klyne
> <https://lists.w3.org/Archives/Public/uri/2018Nov/0003.html[https://lists.w3.org/Archives/Public/uri/2018Nov/0003.html]> that
> using a global URI scheme like in <undefined:sensor-1> would be asking
> for accidental double-bookings and defy the purpose.
> 
> 
> Blank nodes were in a way invented for this purpose, but are sadly
> *not* allowed as properties in RDF, only in "generalized RDF":
> 
> <https://orcid.org/0000-0001-9842-9718[https://orcid.org/0000-0001-9842-9718]> _:favourite_food "Spaghetti" .
> 
> _:favourite_food a rdf:Property ;
> rdfs:label "favourite food" .
> 
> 
> Beyond requiring Generalized RDF the above has a problem that every use
> of the property will be unique (e.g. it will not be Linked data)
> 
> You can of course use local identifiers like <#favourite_food> but then
> again it would be local to each document. You can gather these
> user-provided properties in a user-local URI, e.g.
> 
> <http://example.com/user/1337/vocab#favourite_food[http://example.com/user/1337/vocab#favourite_food]>
> 
> Then each user can at some point further define what they mean by their
> home-made proprties.
> 
> 
> 
> If you are for some reason not able to tie this to a domain name (e.g. a
> distributed scheme where user types in an ad-hoc name) I would recommend
> to use UUIDs.
> 
> <https://orcid.org/0000-0001-9842-9718[https://orcid.org/0000-0001-9842-9718]>
> <urn:uuid:0ef595e6-5d9f-469c-b351-8565a0b081dd> "Spaghetti" .
> 
> <urn:uuid:0ef595e6-5d9f-469c-b351-8565a0b081dd> a rdf:Property ;
> rdfs:label "favourite food" .
> 
> 
> The problem then is reduced to keeping track of these UUIDs for re-use
> (e.g. an auto-complete list when a user types in "food")
> 
> I think a similar approach to "dynamic properties" is used in Graham's Annalist.
> http://annalist.net/documents/tutorial/annalist-tutorial.html#_add_simple_fields_to_a_data_record[http://annalist.net/documents/tutorial/annalist-tutorial.html#_add_simple_fields_to_a_data_record]
> 
> 
> BTW, SKOS is probably a good starting point if the user also tries to
> slightly organize such ad-hoc vocabularies in a non-ontological
> manner <https://www.w3.org/TR/skos-primer/[https://www.w3.org/TR/skos-primer/]> but want to relate it to
> existing terms e.g.:
> 
> <urn:uuid:0ef595e6-5d9f-469c-b351-8565a0b081dd> a skos:Concept ;
> skos:prefLabel "favourite food" .
> skos:relatedMatch <https://schema.org/LikeAction[https://schema.org/LikeAction]> ;
> skos:broadMatch <http://purl.org/spar/cito/likes[http://purl.org/spar/cito/likes]> .
> 
> As you've here used global UUIDs "anyone" can provide such a mapping
> later, which I think touches on what you were considering in your
> original email.
> 
> --
> Stian Soiland-Reyes
> The University of Manchester
> https://www.esciencelab.org.uk/[https://www.esciencelab.org.uk/]
> https://orcid.org/0000-0001-9842-9718
> 
>  
> 

-- 
Hugh
023 8061 5652

Received on Monday, 19 November 2018 13:20:23 UTC