Re: Small remarks on TermMap and PrefixMap in the RDF Interfaces document

Ivan Herman wrote:
> Nathan, Manu
> 
> I am doing some sort of a proof-of-concept implementation of the interfaces on top of RDFLib. I do not think it will every have any production quality but it forces me to go into some details...
> 
> As such, here are some comments on the Term and Prefix maps; these are mostly missing details in the spec:
> 
> - There should be a reference to the RDFa Core's CURIE definition to define what a valid CURIE is. That also means that for a resolve operation in the PrefixMap it should be explicitly said that an invalid CURIE results in a null return value. 

Perhaps, need to look in to this closely, as it has to support all kinds 
of prefixes, without serialization specific limits, it may well be that 
turtle and sparql's definition, or perhaps N3, is different to RDFa's 
(particularly what can be used for the first char).

> Also, what happens if the curie is ":" (which should return the default URI if set, I guess). 

yes, well noted.

> Another point is: are PREFIX:term and prefix:term identical (as for RDFa Core 1.1)? 

Oh dear, this could be impossible to define without really changing the 
interfaces, they are defined such that you can use native 
keys/attributes on the PrefixMap:

  prefixes.rdFA = 'http://..';

which makes it impossible to normalize to lower case, we could however 
have the resolve method do a case insensitive comparison.. we probably 
need to address this with some guidance, good catch.

> Also, a _:asfdasfd is not a valid CURIE and should be ignored. 

Perhaps.. it may have uses in the interfaces for skolemization though..

> As I said, most of these are actually covered in the RDFa Core, and it is probably the best to refer to that for the details. But another possibility is to carry these over to this document.

Can we have the RDF Interfaces deferring to RDFa Core on things like 
this? should it not be something in the RDF specs?

> Same holds for the Term mapping, eg, that the term is an ncname...
> 
> - PrefixMap addAll method: the text on override says:
> 
> "If true then conflicting prefixes will be overridden by those specified on the PrefixMap being imported, by default imported prefixes augment the existing set."
> 
> I am not sure what this means for the 'false' case. My expectation is that in the case of conflict no overriding occurs and the prefix setting in the 'other' map is ignored, but the way I can read the text is as if I would add the same prefix with another reference, ie, having the same prefix twice. That would certainly be wrong...

Indeed, we can clarify that in the text.

> Also: does the override occurs for the default URI, too? I would expect yes if the local value is Null, but that is not clear...

Good point, I need to check if I've even implemented that, certainly 
seems it should override the defaults! (need to check if you can even 
access the defaults though..)

> Manu, now that we have a published document, it may be worth adding these as a separate ISSUE, not to loose it along the way...

Agree.

Cheers Ivan,

Nathan

Received on Wednesday, 11 May 2011 11:22:08 UTC