W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > April 2011

Re: RDF API updates

From: Ivan Herman <ivan@w3.org>
Date: Sat, 23 Apr 2011 10:28:51 +0200
Cc: RDFA Working Group <public-rdfa-wg@w3.org>
Message-Id: <C0920BD6-1043-4AED-BC6B-0B913A017D7E@w3.org>
To: nathan@webr3.org

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

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... 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. Maybe the RDF WG will do it, let us see what happens, 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. 

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

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

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?

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

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

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



[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 08:28:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:51 UTC