Re: URI/IRI concrete and abstract syntax

Changes to use "IRI" throughout done except in section 11, which I will leave to 
Eric, and the one case where it is talking about the data format (Turtle) for 
examples.

v1.372

 Andy



Dan Connolly wrote:
> We currently have:
> 
>   "let RDF-U be the set of all RDF URIs"
> 
>   http://www.w3.org/2001/sw/DataAccess/rq23/#defn_RDFTerm
>   $Revision: 1.319 $
> 
> (I had to do view-source to get that fragid. While perhaps
> my browser should do better, I'd like to have an index
> of abstract syntax terms at the end or something.)
> 
> The term at the other end of the link is actually
> "RDF URI reference"...
> 
> [[
> A URI reference within an RDF graph (an RDF URI reference) is a Unicode
> string [UNICODE] that:
> 
>       * does not contain any control characters ( #x00 - #x1F,
>         #x7F-#x9F)
>       * and would produce a valid URI character sequence (per RFC2396
>         [URI], sections 2.1) representing an absolute URI with optional
>         fragment identifier when subjected to the encoding described
>         below. 
> ]]
>   -- http://www.w3.org/TR/rdf-concepts/#dfn-URI-reference
> 
> The discrepancy is probably due to a comment from me.
> 
> The good news is that definition of the term "RDF URI reference"
> turns out to be the same as the slightly more modern term, "IRI"
> from RFC3987:
> 
> [[
>    IRI reference: Denotes the common usage of an Internationalized
>       Resource Identifier.  An IRI reference may be absolute or
>       relative.  However, the "IRI" that results from such a reference
>       only includes absolute IRIs; any relative IRI references are
>       resolved to their absolute form.  Note that in [RFC2396] URIs did
>       not include fragment identifiers, but in [RFC3986] fragment
>       identifiers are part of URIs.
> ]]
>  -- http://www.ietf.org/rfc/rfc3987.txt
> 
> 
> So I suggest replacing RDF-U with just I ala...
> 
>  Definition: RDF Term
> 
>  let I be the set of all IRIs
>  let RDF-L be the set of all RDF Literals
>  let RDF-B be the set of all blank nodes
> 
>  The set of RDF Terms, RDF-T, is I union RDF-L union RDF-B.
> 
> followed, outside the definition box, by:
> 
>   Note that all IRIs are absolute; they may or may not include fragment
>   identifiers[RFC3987, section 1.3]. Also note that IRIs include URIs
>   (and URLs). This definition matches the
>   definition of RDF URI Reference from [12].
> 
> I suggest striking
> 
>   An RDF Term is anything that can occur in the RDF data model.
> 
> or move it outside the box and phrase it as:
> 
>   This definition of RDF Term collects several basic
>   notions from the RDF data model.
> 
> In the concrete syntax, i.e. the grammar, it's all IRI references.
> So this is pretty good...
> 
> [3]   BaseDecl   ::=   'base' QuotedURIref
> 
> probably better as QuotedIRIref.
> 
> But...
> 
> [12]   SourceSelector   ::=   URI
> 
> should be
> 
> [12]   SourceSelector   ::=   IRIref
> 
> and
> 
> [63]   URI   ::=   QuotedURIref | QName
> 
> should probably be
> 
> [63]   IRIref   ::=   QuotedIRIref | QName
> 
> likewise
> [41]   VarOrURI   ::=   Var | URI 
> should be
> [41]   VarOrIRIref   ::=   Var | IRIref
> 
> Also...
> 
> [69]   <Q_URIref>   ::=   '<' ([^> ])* '>' /* A URI relative reference :
> RFC 3869 */
> 
> should be...
> 
> [69]   <Q_IRIref>   ::=   '<' ([^> ])* '>' /* A IRI reference : RFC 3987
> */
> 
> and let's move that comment into the prose of the spec...
> how about under "Query Term Syntax".
> 
> We should probably be more clear about whether this
> is a sparql query or not:
> 
>   SELECT ?x WHERE { <foo###bar> dc:title ?x }.
> 
> REQUEST FOR TESTCASE.
> 
> I suggest that yes, it's a SPARQL query as defined by the
> grammar, but it's erroneous; i.e. it's in the same category
> as queries that don't obey the limitations on where variables
> can go when using OPTIONAL.
> 
> So we probably need a new kinda of test case.
> 
> 
> I dunno if we should rename sop:isURI .
> 
> Huh? what's this?
> 
>   RDF terms are identified by r:term and the constituant subclasses:"
> 
>   types of RDF terms with the prefix r:. SPARQL operators are named
>   with the prefix sop:.
> 
> what are r: and sop: bound to?
> 
> 
> Under 11.2.3.4 sop:isBlank it says
>   This query matches the people with a name and an mbox which is a URI:
> but the query seems to be about matching blank nodes.
> (the data should have some non-bnode people to make the distinction
> more clear).
> 
> This is sorta use-mention-buggy:
> 
>  (foaf:mbox should only have a URI as its object)
> 
> suggest:
> 
>  the range of foaf:mbox is mailbox, not literal.
> 
> 
> 
> Scanning for occurences of "URI" in the document, I find:
> 
>   When undeclared, the prefixes below stand in place of the URIs given:
> 
> which sounds like part of the specification of the syntax of SPARQL,
> but it's in a "Document conventions" section. I suggest changing that
> to something like:
> 
>   In this document, many examples assume the following namespace
>   prefix bindings:
> 
> 
> next I find:
> 
>   The terms delimited by "<>" are relative URI references [RFC 3986].
>   After parsing, these are resolved to give URIs.
> 
> which is pretty good, but (a) the can be absolute too, and (b) they
> should be internationalized and (c) we should mention a base IRI
> somehow. Is a base IRI an input to a parser? I suppose that's one
> way to look at it. But I suggest:
> 
>   The terms delimited by "<>" are IRI references [RFC 3987].
>   They stand for IRIs, either directly or relative to a base IRI.
> 
> next:
> 
>   or an optional datatype URI
> 
> s/URI/IRI/
> 
>  Because URIs can be long, SPARQL provides an abbreviation mechanism.
> 
> s/URI/IRI/ . not critical, since this is informative text. Hmm... maybe
> "IRIs are just like URIs (and URLs even) but internationalized" should
> go somewhere earlier.
> 
> Also: I'd say
> 
>  Because URIs can be long and repetetive, ...
> 
> my mailer says that's spelled wrong. Oh well. never mind.
> 
> 
> next...
> 
>   The base URI for the resolution of relative URIs [RFC 3869] can
>   be explicitly declared with the BASE keyword.
> 
> s/URI/IRI/ . And put that in a separate para. Maybe add an example,
> even.
> 
> 
> next...
> 
> 
>  Turtle allows URIs to be abbreviated with prefixes:
> 
> s/IRI/URI/.
> umm... didn't we just cover that?
> 
>  the subject, which is an RDF URI reference or a blank node
>  the predicate, which is an RDF URI reference
>  the object, which is an RDF URI reference, a literal or a blank node
> 
> s/RDF URI reference/IRI/ 3x
> 
> next...
> 
>   and datatype URI both match exactly
> 
> s/URI/IRI/
> hmm... be explicit about the fact that it's the resovled IRI
> we're comparing, not the possibly relative or qname form?
> 
> next...
> 
>   zero or more named graphs, identified by URI reference.
> 
> s/URI reference/IRI/
> 
> next...
> 
>   and each ui is a URI
>   the GRAPH keyword allows access to the URIs naming the graphs
>  bound to URIs of the graph being matched
> 
> s/URI/IRI/ 3x
> 
> next...
> 
>   The query below uses the graph with URI
> http://example.org/foaf/aliceFoaf
> 
> 
> s/URI/IRI/ optional. It's also a URI.
> 
> next...
> 
>  Each time a graph is read into the aggregator, it is given a URI
>  by the local system.
>  ... a different URI by the system
> 
> s/URI/IRI/ x2
> 
> next...
> 
>   # Graph: locally allocated URI: urn:x-local:graph1
> 
> Please don't use x- nor unregistered urn namespaces.
> Use the example domain:
> 
>   # Graph: locally allocated URI: cid:rnd123@example
> 
> next...
> 
>   The URI for the date datatype has been abbreviated
> 
> s/URI/IRI/ (optional. it's also a URI)
> 
> next...
> 
>  g is a URI where g
> 
> s/URI/IRI/
> 
> next...
> 
>   The FROM clause gives a URI that ...
>   A query processor may use these URIs ...
>   The FROM clause a single URIs that indicates ...
>   A query can supply URIs for the named graphs
>   3. URIs
> 
> s/URI/IRI/ x5
> 
> next...
> 
>   with URI label
> 
> s/URI/IRI/ (optional. it's also a URI)
> 
> next...
> 
>   directly named by URI,
> 
> s/URI/IRI/
> 
> and so on (I stopped auditing at Explicit URIs...)
> 
> 
>

Received on Monday, 6 June 2005 11:09:09 UTC