Range of void:uriSpace is currently undefined

[GoogleCodeExporter]

The range of void:uriSpace is currently undefined. There are two proposals:

a) Make it a resource (URI).
b) Make it a literal.

Original issue reported on code.google.com by richard....@gmail.com on 14 Dec 2010 at 11:46

[GoogleCodeExporter]

Issue 92 has been merged into this issue.

Original comment by richard....@gmail.com on 12 Jan 2011 at 3:19

[GoogleCodeExporter]

Arguments for making it a literal:

- it may not be resolvable
- it's not supposed to name anything, it's just a syntactic substring of other 
URIs that name something
- it may name something else that is not the URI space, such as the dataset or 
the website
- RDF browsers may not show it as a URI but as an abbreviated CURIE or display 
an rdfs:label picked up from the dataset resource
- it's analogous to cases like vann:preferredNamespaceUri, where URIs are 
treated as literals
- if treated as resource, one might infer a misleading void:uriSpace statement 
with owl:sameAs reasoning

Arguments for making it a resource:

- syntactically, it is a URI
- one gets URI validation for free
- if treated as a resource, this leaves open the option of adding properties to 
it or making it resolvable
- the RDF data model has a dedicated construct for URIs, so that should be used 
for URIs
- users may not be able to follow the rather theoretical arguments for why some 
URIs are treated as URIs and others as literals
- this makes it easy to do the right thing: if it looks like a URI, treat it as 
a URI

Options for proceeding

- Keith and Richard keep discussing till issue is settled (unlikely)
- Drop from this release and postpone
- Leave the range open, provide examples for both in the spec, and describe the 
disagreement
- Get external feedback in the hope that it surfaces new information

Original comment by richard....@gmail.com on 1 Feb 2011 at 1:20

[GoogleCodeExporter]

Related discussion here:
http://www.semanticoverflow.com/questions/2882/why-are-uris-sometimes-treated-as
-literals-in-rdf

This shows strong support for Keith's general position among Semanticoverflow 
contributors.

Regarding the use of URIs vs literals in voiD, the major inconsistency that's 
bothering me is regarding void:uriSpace vs void:sparqlEndpoint and 
void:uriLookupEndpoint. On a high level, these three serve equivalent 
functions: They indicate a prefix that, if appended with some more characters, 
produces a meaningful resolvable URI. Why should they be treated differently?

Original comment by richard....@gmail.com on 3 Feb 2011 at 11:16

[GoogleCodeExporter]

There are 2 parts to this:

1. Richard's view was that strings that conform to URI syntax (in the object 
position of a triple) should always be marked up as URIs; mine was that there 
are (rare) times when it is useful to mark them up as literals if you don't 
want RDF systems to treat the string as an identifier.

2. Is void:uriSpace one of those rare times? This property was proposed by 
Richard, so I defer to him on its intended semantics. But going by my 
understanding of the motivation for it, the problem with making it point to a 
resource is that the primary (and currently only) useful thing we can say about 
it is what its URI should look like. And URIs are meant to be opaque. I think 
if we are interested in the characters of the uriSpace itself, rather than 
whatever they might identify, the range has to be rdfs:Literal.

re: sparqlEndpoint, we don't say in the guide that the identifier for the 
endpoint should be its URL (though that is the default assumption I guess), and 
the SSD vocab has an sd:url property that can be used if you want the id and 
the URL of the service to be different.

re: uriLookupEndpoint - yep, you're right there; it's a resource whose URI you 
append characters to get a resolvable URI. Not ideal, but was good solution 
that doesn't have the same practical problems that uriSpace range resource does 
(uriLookupEndpoint URIs very likely to be unique, and return something useful; 
there are obvious useful ways the Endpoint could be described if an appropriate 
vocab exists - accept mimetypes, accepted parameters, etc ).

A distinction between uriLookupEndpoint+sparqlEndpoint and uriSpace is maybe 
more apparent if uriPrefix (one of your earlier suggested names) is used. 
uriLookupEndpoint + sparqlEndpoint names suggest that they point at resources, 
uriPrefix suggests that it points to a portion of a URI (not whatever that URI 
might identify).

Original comment by K.J.W.Al...@gmail.com on 3 Feb 2011 at 5:21

[GoogleCodeExporter]

Post discussion with Richard, a draft definition:

void:uriSpace 
   a rdf:Property ;
   rdfs:label "URI Space"@en ;
   rdfs:comment """A namespace in which the URIs of the resources in the dataset are minted."""@en ;
   rdfs:range rdfs:Literal ;
   rdfs:domain void:Dataset ;
   rdfs:seeAlso void:uriRegexPattern ;
   rdfs:isDefinedBy void:
.

Original comment by K.J.W.Al...@gmail.com on 4 Feb 2011 at 9:53

[GoogleCodeExporter]

In today's editors call we decided to define the range as rdfs:Literal, as per 
Keith's proposal.

Original comment by richard....@gmail.com on 9 Feb 2011 at 1:56

[GoogleCodeExporter]

Added a note regarding the range in r188. And closing as per today's call

Original comment by richard....@gmail.com on 17 Feb 2011 at 4:28

• Changed state: Fixed