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

Hi Tim,

Sorry for not responding to this earlier on, I fear the current RDF API 
draft may not have made things clear on the modularity side of things.

The API provides interfaces for PrefixMap, TermMap and then a merged 
interface Profile which is intended to be used as a per-context 
URI/term/prefix resolution mechanism.

The RDFEnvironment interface extends the Profile interface and gives 
access to a default set of term/prefix mappings, typically those 
provided by the environment (for instance the library implementing the 
API, or the document when working in a browser), however this is just 
the default, users can use this default, or use their own per 
script/context Profile for resolution, or import from an external profile.

Essentially each modular component can use it's own Profile to resolve 
terms and prefixes, without hindering interoperability or conflicting 
with the default, or other, profiles.

This way somebody using a small javascript in an RDFa document can use 
the terms and prefixes from the document, whilst a third party plugin 
can be using it's own profile, whilst another script pulling or adding 
information to a store of some kind can be using it's own profile - thus 
ensuring that the API is fully modular, interoperable, and that each 
module uses it's own term and profile maps for resolution.

To compliment this, all the other API methods use full IRIs only, and as 
such have no awareness, or reliance upon, profiles and environments; 
that is to say, terms and prefixes are only used within the scripting 
environment / userland code, and not by any of the components of the RDF 
API, much in the same way that only IRIs are stored in a quad store, 
whilst the SPARQL query language allows people to declare and use prefixes.

In code:

   $rdf.resolve("foaf:name");
   // uses default, expected functionality when creating javascript code
   // inside, and using data from an RDFa document.

   myprofile.resolve("foaf:name");
   // uses a custom profile of mappings for prefix/term resolution,
   // ensuring that modules get their own expected functionality anywhere
   // they are used

   lib.resolve("foaf:name"); // as above, another different context

   foaf('name'); // also fully compatible

Hopefully that clarifies, if not, just say,

Many thanks again for the feedback on this important issue,

Nathan

Tim Berners-Lee wrote:
>  Modularity
> 
> 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
> 
> 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 
> foadname = $rdf.resolve("foaf:name") is not.
> 
> 
> Tim
> 
>

Received on Tuesday, 4 January 2011 17:13:02 UTC