Re: RDF API updates

Hi Ivan,

Thanks for the feedback! in-line form here:

Ivan Herman wrote:
> Nathan,
> 
> Terrific! I only had a cursory look at thing right now, I will go through the document in more details but that may not be before the end of Easter. Some comments, though:
> 
> 1. A question that just came to me while reading the Literal interface definition (2.3.4). If you look at the definition of datatypes in the RDF Semantics document[1] it talks about value space and lexical space, about the lexical-to-value mapping, etc. I think using these notions in the text would make it clearer. For example, the current description does not make absolutely clear whether the 'value' attribute is the value of the specific literal in the datatype's value space (ie, the result of the value mapping) (which I think it is, but making it clearer might help).

Yes, the mappigns to IDL and ECMAScript are all in the "Datatype Map:" 
in that section, and the guidance "The native value of the literal, if 
the datatype of the literal is not known by the implementation the nodes 
value MUST be the lexical representation of the value."

> The term you use 'native value' is not really defined. We do not have to define these things ourselves, b.t.w., we can just refer to the existing RDF spec...
> 
> Actually... I wonder whether it makes sense for applications to store in the Literal object _both_ the lexical value of the literal and the value in the datatype's value space, making it somehow clear that equality is base on the equality in the value space... Just a thought.

Perhaps, unsure whether we should require them to do it though? Will 
look in to the text again and see where it can be clarified (with 
additional text, or by pointing to other specs).

Gavin Carothers also raised a related issue, lang_match equality, we 
haven't catered for it anywhere in the API - as in we cater for exact 
match, but not for "EN" matching "en-US" and "en-GB", unsure if we 
should cater for this or not?

> 2. The second issue is, actually, a bit related to this and, again, relates to TripleSets. Sorry if I touch on some nerves, it is really not my intention...

No problem, I know it's not personal, and fully understand the situation 
:) You're just doing your job, and I'm glad you are!

> I think that, at this point, there is no reason to say that a TripleSet is a subclass of Literal. I do not think any of the interfaces would change if we simply say that a TripleSet extends an RDFNode, and that is all what we can say at the moment. We do not necessarily define Graph Literals...
> 
> I feel I owe some sort of an explanation here, to avoid unnecessary bad feelings here. _Personally_ and intellectually I am actually in favour of the concept of a graph literal. (An that is independent of the fact whether a literal can be in subject position or not.) But... beyond the issues I raised at the call on consistency of recommendations, we have to realize that if _we_ define a graph literal (and by subclassing TripleSet from Literal this is what we do) then we have to do much more than just saying this. What we would have to do then is to define a new RDF Datatype properly in the sense of [1]. We have to define exactly what the lexical space is, what the value space is, what the lexical-to-value mapping is (in terms of [1]), we have to define things like what does equality mean in the datatype's value space (bnodes...:-), etc. All this can be done of course, but it _is_ a non-trivial amount of work, and I just do not believe this is something that should be done 
by an API document.

I agree, and realize there would be a lot of work - personally I'm fully 
expecting to have that interface ripped out of the API in the future, I 
just wanted to ensure that it was:
a) considered (as in nothing was defined in the spec that would preclude 
libraries implementing such an interface)
b) in the document in advance of the RDF WG in the hope that ->

> Maybe the RDF WG will do it, let us see what happens

the above!

> but this is not for this group. By defining a TripleSet as extending an RDFNode, we leave the door open to whoever will handle that. 

Why don't we just remove it from the API - it's unsparqlable as has been 
pointed out, it's not defined in RDF anywhere, and the odds of it being 
defined, are well, you know :) Perhaps if it is then we can add it back 
in at a later date - one must make compromises where one can.

> By the way, I think we agreed in adding an editorial node to that part, referring to the discussion at the RDF WG on that matter, and that this interface might change (including its name) as the issue progresses over there

We do, in section 2.1 - however, as above, will just remove it.

> 3. (Minor) You have a remark on the UTF-8 version of NTriples, which is of course completely valid. But I would rather see that remark as an explicit note for the reader which draws the attention on the fact that NTRiples is ASCII based, but that the RDF WG may refresh that, so this detail may change in future releases of the draft

Okay, will do.

> 4. The (node,node,node) issue... as far as I remember we agreed that there would be some sort of a constraint somewhere if we want to reinforce the RDF concept restrictions. I have not found that... I looked at the Triple interface, at the createTriple method, ... How do you plan to handle that?

I'm at a loss of what to do here to be honest, as you know I feel 
exceptionally strongly about maintaining the (node,node,node) 
definition, and the only way I can see to constrain it (taking in to 
account an IDL definition of the createTriple method would be needed) is 
to add in another interface say RDFResource which both NamedNode and 
BlankNode extend and use that in the subject slot, and NamedNode in the 
property slot, which basically will preclude node node node usage.

The only thing I could think of for the time being was to add the text 
at the start of section 2:

[[
The RDF Concept Interfaces in this specification provide a low level API 
for working with RDF data.

The concepts described in this specification are more generalized than 
those defined by the RDF Data Model [RDF-CONCEPTS]. Whilst this may 
appear to be a mismatch, the RDF specification is intended to define a 
notation for transmitting data on the Web, however this specification 
defines a set of interfaces for working with that data, behind the 
public interface, where more generalized notions of Triples are often 
required by libraries and modules.
]]

Guidance?

> 5. I actually found two minor editorial issues on the document, I took the liberty to change the -src.html file. Namely:
> 
>   5.1 (Minor) in the status section the name of the Working Group should change:-)
> 
>   5.2. (Minor) a number of people have joined the WG in the last few days[2]. Which is of course great, but that means that Appendix A should be refreshed...

Thanks and thanks! (Minor, should it also say "the members of the RDF 
Web Application WG were" ?)

> 6. (Minor) I wonder whether a class diagram would be useful to give a visual representation of the interfaces. Do not deal with this now, it may not be necessary for the FPWD; I may play with that... It helps me in understanding things in the first place:-)

Sounds like a good idea!

> And to avoid any misunderstandings here: this document is 99% at the publication ready level. A deep bow towards Scotland...

:) thanks, and thanks to all of course for all the hard work over the 
years and recently that's gone in to this.

Best,

Nathan

> Thanks
> 
> Ivan
> 
> [1] http://www.w3.org/TR/rdf-mt/#dtype_interp
> [2] http://www.w3.org/2000/09/dbwg/details?group=44350
> 
> 
> 
> On Apr 22, 2011, at 19:20 , Nathan wrote:
> 
>> Hi All,
>>
>> I've done just uploaded a new draft of the RDF API, however haven't quite finished reviewing yet and may have a few more minor changes to the IDL and changes to the prose.
>>
>> link:
>>  http://www.w3.org/2010/02/rdfa/sources/rdf-api/Overview-src.html
>>
>> Changes so far are:
>>
>> changed RDF Concept Interfaces introduction.
>>
>> changed Aliases back to Terms.
>>
>> changed GraphLiteral to TripleSet and added an instability notice.
>>
>> removed Graph.the
>>
>> clarified the difference between Graph.merge and Graph.import
>>
>> added a Graph match(in RDFNode subject?, in RDFNode property?, in RDFNode object?, in optional unsigned long limit) method, which is pretty self explanatory, pass in an optional subject, property, object, and get back a new graph containing all triples which match the given arguments. And it's got a limit feature.
>> note: There were so many different ways in which this could be defined, the other main alternative I considered was the method accepting a single MatchTriple or array or MatchTriples where a MatchTriple was a Triple where each of subject, property, object was optional - however I thought that was getting too close to query functionality, would require other methods to create matchtriples, and raised lots of questions about AND/OR functionality and the like. Open to discussion feedback of course.
>>
>> clarified the description of Graph.apply
>>
>> changed PrefixMap.resolve return null if prefix not set
>>
>> removed import*FromGraph methods from TermMap, PrefixMap and Profile
>>
>> removed Profile.base
>>
>> removed Parser.profile
>>
>> changed the try method on TripleAction to 'run'
>>
>> got rid of the NCName restrictions. defined prefix/term as string w/ no colon or whitespace
>>
>> Best,
>>
>> 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 Saturday, 23 April 2011 15:30:50 UTC