Re: RDF API: fusing TermMap and PrefixMap

Hi Benjamin,

We seem to want to harmonise terms and prefixes (a good thing) whilst
for some reason still maintaining their distinction!

Anyway, the problem with this proposal is that it uses the URI pattern
to determine whether a prefix or a token is being created, and
therefore imposes a limitation on the possible URIs that can be
created when resolving.


LIMITING THE URI UNIVERSE

This is exactly the kind of problem that prompted the creation of
CURIEs; in the past, URIs were compacted using QNames, which meant
that they couldn't be used to create abbreviated URIs for patterns
like:

  <http://example.org/company/12345>

(A QName cannot be of the form prefix:12345.)

We seem to be doing the same here, by saying that tokens must follow
one pattern, and prefixes follow another; by making them both a subset
of the total URI universe they each have URIs that they can't express.


ASYMMETRY BETWEEN SET() AND RESOLVE()

Also, the mirror of this is that the resolve() function can now create
a class of very subtle bugs that would be difficult to spot in your
code. To illustrate, if you did this:

  iris.set("taxonomy", "http://example.org/company/");
  assert(iris.resolve("taxonomy") === "http://example.org/company/");

one might expect "taxonomy" to map to the original URI (i.e., the
assertion is true), but it doesn't because only the prefix table would
be searched by resolve() and not the token table. Instead I would have
to do this (note that additional colon):

  assert(iris.resolve("taxonomy:") === "http://example.org/company/");

This forces resolve to search the prefix table which is where it finds the URI.

This would be very difficult to explain to developers, since although
the set() and resolve() functions /appear/ to be symmetrical they
aren't, and whether they behave symmetrically or not is purely
dependent on the URI pattern. (Something which is made more confusing
when you see that get() and remove() make no such distinction between
tokens and prefixes.)

Regards,

Mark


On Wed, Jan 19, 2011 at 12:54 PM, Benjamin Adrian
<benjamin.adrian@dfki.de> wrote:
> Hi,
>
> Manu asked me to look for a way to fuse TermMap[1] and PrefixMap[2] in the
> RDF-API.
>
> [1] http://www.w3.org/2010/02/rdfa/sources/rdf-api/#term-maps
> [2] http://www.w3.org/2010/02/rdfa/sources/rdf-api/#prefix-maps
>
> I recommend using an IriMap interface that fuses the interfaces TermMap and
> PrefixMap. Any comments from your side?
>
> [NoInterfaceObject]
> interface IriMAP {
>  getter DOMString get(in DOMString abbreviation);
>  setter void set (in DOMString abbreviation, in DOMString iri);
>  deleter void remove (in DOMString abbreviation);
>  DOMString resolve (in DOMString abbreviation);
>  DOMString shrink (in DOMString iri);
>  void setDefault (in DOMString iri);
>  IriMapMap import (in IriMap abbreviations, in optional boolean override);
>  IriMap importFromGraph (in Graph graph, in optional boolean override);
> }
>
> Short Example of using the IriMap:
>
> // create a new prefix mapping for the prefix "rdfs"
> iris.set("rdfs", "http://www.w3.org/2000/01/rdf-schema#")
>
> // resolve a known CURIE
> iris.resolve("rdfs:label");
> // --> "http://www.w3.org/2000/01/rdf-schema#label"
>
> // create a new token mapping for the token label
> iris.set("label", "http://www.w3.org/2000/01/rdf-schema#label")
>
> // resolve a known token
> iris.resolve("label")
> // --> "http://www.w3.org/2000/01/rdf-schema#label"
>
>
> Compared to the current spec, the necessary interface changes that specify
> this IriMap are:
>
> 1. set:
>  Parameter      Type            Description
>  abbreviation   DOMString       The abbreviation must be a valid NCName
>  iri            DOMString       An IRI, as defined by [IRI].*
>
> * If the value of the parameter iri is classified as Namespace IRI that is
> an IRI that ends either with a character value "/" or a character value "#",
> then abbreviation is handled as prefix value that substitutes the Namespace
> IRI.
> Else, if iri is not classified as Namespace IRI, then abbreviation is
> handled as token value that substitutes the IRI.
>
>
> 2. resolve:
>  Parameter      Type            Description
>  abbreviation   DOMString       CURIE to resolve.**
>
> ** If abbreviation is a CURIE, then resolve the abbreviated IRI as prefix
> (for example "rdfs:label" is resolved as
> "http://www.w3.org/2000/01/rdf-schema#label"). Else, if abbreviation is a
> valid NCName, then resolve the abbreviated IRI as token (for example "label"
> is resolved as "http://www.w3.org/2000/01/rdf-schema#label").
>
> 3. get, remove:
>  Parameter      Type            Description
>  abbreviation   DOMString       The term must be a valid NCName. ***
>
> *** It deletes both, existing tokens and prefixes having the value of the
> parameter abbreviation.
>
> 4. setDefault, shrink, importFromGraph, import: These methods work similar
> in TermMap and PrefixMap , so they won't change in IriMap.
>
>
> Best regards,
>
> Ben
>
> --
> __________________________________________
> Benjamin Adrian
> Email : benjamin.adrian@dfki.de
> WWW : http://www.dfki.uni-kl.de/~adrian/
> Tel.: +49631 20575 1450
> Twitter: http://twitter.com/BenBanBun
> Skype: benbanbun
> __________________________________________
> Deutsches Forschungszentrum für Künstliche Intelligenz GmbH
> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
> Geschäftsführung:
> Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats:
> Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> __________________________________________
>
>

Received on Sunday, 30 January 2011 17:10:35 UTC