Modularity problem Re: PROPOSAL to close ISSUE-61: Does the RDFa API need a vocabulary helper

 Modularity

There is clearly a modularity problem with the shared prefix map.

I feel that having a global namespace prefix map associated with a store is useful for 
small applications, but bad for large ones.

Take for example an RDF system run by a browser,
in which everything which happens is stored, including the HTTP request/response
history, and information pulled from any pages the user loads.

This is used, ay, by many add-ons and plugs and applets which 
the user may install to access the data.

The problem is, that while these apps must access the same store, they 
cannot assume that they share ideas about prefixes.

This problem is exacerbated when apps use common libraries
which deal with certain types of data (say social data or statistical data).
Those common libraries must be able to be written using shorthand for
the namespaces they deal with -- but without danger of polluting 
or conflicting with the namespaces in the global prefix map.

Javascript already has a dangerous global namespace which
developers of libraries have learned to almost completely avoid.
typically each library adds just one term to that global symbol space.

We already have similar problems with CSS classes in 
javascript libraries -- there are dangers of clashes between classes 
added by different libraries. 

Ideally, any local names have javascript scope. This is why 
foafname = foaf('name')  is safe, and why 
foafname = $rdf.resolve("foaf:name") is not.

Note that JQuery solves this by allowing one to generate a
clone of a JQuery and then add custom local bits, such as prefixes, which simulates
a sort of nested hierarchical scope.

Tim


On 2011-01 -02, at 23:10, Manu Sporny wrote:

> If there are no objections to this proposal in 7 days, we will close
> ISSUE-61: Does the RDFa API need a vocabulary helper.
> 
> http://www.w3.org/2010/02/rdfa/track/issues/61
> 
> This issue concerns the availability of a mechanism to help developers
> resolve CURIEs. There were two mechanisms that were requested, the first
> would allow a developer to create a CURIE resolver object and use it
> like so:
> 
> var foaf = graph.ns("http://xmlns.com/foaf/0.1/");
> var foafname = foaf("name");
> // at this point, foafname == "http://xmlns.com/foaf/0.1/name"
> 
> The second mechanism would allow a developer to resolve a CURIE using a
> simple method call:
> 
> document.data.setMapping("foaf", "http://xmlns.com/foaf/0.1/");
> var foafname = document.data.resolve("foaf:name");
> // at this point, foafname == "http://xmlns.com/foaf/0.1/name"
> 
> A number of changes have been made to the RDFa API since this issue was
> raised:
> 
> 1. The RDFa API has been split into a low-level RDF API specification
>   and a high-level RDFa API specification. Working with vocabulary
>   helpers and CURIE resolvers is considered a low-level/expert task
>   and has been moved into the RDF API as a result.
> 2. A setMapping() method has been added to the high-level RDFa API
>   specification so that developers may specify how CURIEs are resolved.
>   All arguments passed to the high-level API are designed to allow
>   the specification of CURIEs - that is, CURIE resolution is done
>   automatically for the developer. The RDFa API has been deliberately
>   kept simple to ensure that beginner developers do not have to deal
>   with manually resolving CURIEs in the most common cases.
> 3. The RDF API now provides a direct mechanism for specifying CURIE
>   mappings via the PrefixMap, TermMap and Profile interfaces. The
>   RDFa WG is still considering combining the PrefixMap and TermMap
>   interfaces, but that is a separate issue from what the CURIE
>   resolution mechanism should look like.
> 
> The following example in the RDF API demonstrates how prefixes can be
> set and resolved using the PrefixMap/TermMap interface:
> 
> http://www.w3.org/2010/02/rdfa/sources/rdf-api/#widl-PrefixMap-shrink
> 
> The Profile interface, which is the base interface for the
> RDFEnvironment interface, exposes the .resolve() method, which can be
> used to resolve CURIEs based on all known PrefixMap, TermMap, document
> base URL and default vocabulary settings:
> 
> http://www.w3.org/2010/02/rdfa/sources/rdf-api/#widl-Profile-resolve
> 
> For example, the following is possible when using the RDF API:
> 
> var rdf = document.data.rdf;
> rdf.prefixes.foaf = "http://xmlns.com/foaf/0.1/";
> var foafname = rdf.resolve("foaf:name");
> // at this point, foafname == "http://xmlns.com/foaf/0.1/name"
> 
> Given the code above, the following is also possible using the RDF API:
> 
> var short = rdf.prefixes.shrink(foafname);
> // at this point short == "foaf:name"
> 
> One can even create a short-cut resolution mechanism, like so:
> 
> var r = document.data.rdf.resolve;
> var foafname = r("foaf:name");
> // at this point, foafname == "http://xmlns.com/foaf/0.1/name"
> 
> The above demonstrates the low-level CURIE resolution interfaces. The
> following is possible when using the RDFa API (high-level CURIE
> resolution interfaces):
> 
> document.data.setMapping("foaf", "http://xmlns.com/foaf/0.1/");
> var people = document.getItemsByType("foaf:Person");
> 
> The RDF API and RDFa API may be used together, for example:
> 
> document.data.rdf.prefixes.foaf = "http://xmlns.com/foaf/0.1/";
> var people = document.getItemsByType("foaf:Person");
> 
> The RDFa WG has found that having a number of mechanisms to shrink and
> expand CURIEs is important and should be supported. Additionally, the
> RDFa WG has found that being able to use CURIEs directly in method calls
> in both the RDF API and RDFa API is vital for ease of use.
> 
> However, the RDFa WG has also found that having two mechanisms for
> resolving CURIEs may be confusing to developers and does not provide
> enough benefit to warrant the addition of a CURIEResolver interface into
> the RDF API or RDFa API. That is to say, foaf("name") will not be
> supported as a programming pattern - rather "foaf:name" will be
> supported when used with the RDF API and RDFa API methods. If a
> developer desires a coding pattern like foaf("name"), a
> CURIEResolver-like mechanism can be created fairly easily in user-space
> code (as demonstrated above).
> 
> The proposal is to keep the CURIE resolution additions described above
> and specified in the RDF API and RDFa API specifications. A
> CURIEResolver interface will not be supported to ensure a consistent
> mechanism for resolving CURIEs across the RDF API and RDFa API.
> 
> Please comment in 7 days from this post if you object to this proposal.
> If there are no objections within 7 days, ISSUE-61 will be closed.
> 
> -- manu
> 
> -- 
> Manu Sporny (skype: msporny, twitter: manusporny)
> President/CEO - Digital Bazaar, Inc.
> blog: Linked Data in JSON
> http://digitalbazaar.com/2010/10/30/json-ld/
>

Received on Monday, 3 January 2011 14:57:08 UTC