Re: "undefined" URI scheme

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

Received on Monday, 19 November 2018 12:49:19 UTC