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

On May 11, 2011, at 13:21 , Nathan wrote:

<snip/>
> 
> 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://..';
> 

Ha! I actually did not even realize that. My reading from the 'omittable getter' on the interface is that the object should, if possible allow things like

prefixes["rdFA"] = 'http://..' 

(I was not absolutely sure what this 'omittable getter' really means).

But... in RDFa we say something like the prefix should be converted into lower case and then off you go. We can say the same thing here: if you make a set, then these are converted on lower case and that is it. I do not think we should go out of our way to handle the crazy (and probably useless) corner cases...


> 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..

I think we are much safer declaring those as illegal, do not forget all the issues with the values of the same bnodes changing on different runs. I do not think we should go there. If there is a 'advised' way of skolemization in the RDF document, that should be taken separately in my view, ie, some kind of an explicit bnode->skolem method somewhere.

> 
>> 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?

Certainly not the core RDF specs. CURIE is not an RDF concept, which works only with URIs. That being said, the Turtle spec grammar is there (well, will be), we can also refer to that one.

Cheers

Ivan

> 
>> 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


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf

Received on Wednesday, 11 May 2011 11:39:47 UTC