Re: RDF API thoughts

On Jan 11, 2011, at 16:10 , Nathan wrote:

> Hi Toby,
> 
> Comments in line:
> 
> Toby Inkster wrote:
>> Here are some thoughts on the RDF API draft which a recent discussion in
>> the #swig IRC channel helped my clarify in my head.
>> The current RDF API draft is really a Notation 3 API in stealth.
>> The current RDF API draft goes beyond the RDF data model in several
>> ways. I'm a big fan of the Notation 3 data model - the RDF data model
>> comes with various restrictions which are seemingly arbitrary. However,
>> for the RDF API it makes more sense for us to stick with the RDF data
>> model.
> 
> The initial draft API was aimed less at N3, and more at an RDF model with the seemingly arbitrary constraints removed.
> 
> There are essentially four possibly contentious items, listed below with reasons for each
> 
> 1: The loosening of the Triple interface to include any node in any position
> - because this is possibly the most arbitrary restriction on the RDF model, primarily imposed because of serialization limitations rather than for model or semantic reasons.

To be fair, this is not entirely true. There has been long and surprisingly passionate discussion on SWIG about the Literal-as-subject issue that was not bound to syntax

> 
> 2: The inclusion of Graph Literals
> - because they may very well be included in the next revision of RDF, as per the potential RDF WG draft charter.
> 

Per proposed charter:

http://www.w3.org/2010/09/rdf-wg-charter.html#outofscope

this is explicitly listed as out of scope!

I am not saying we should not have it in the RDF API (I have not really made up my mind yet) but we should have our facts right... Sorry:-)


> 3: The removal of the datatype /or/ language constraint on literals
> - because we may move to a place where PlainLiteral, xsd:string and related are joined in a single datatype (which would mean a literal could/may have both a datatype and a language).

Well... yes. One might argue that, in the case of rdf:PlainLiteral, the language tag is 'hidden' in the string itself, I agree that it is nicer on the API level if this is handled separately

> 
> 4: The inclusion of profiles
> - because they are all ready part of RDFa and may be adopted by RDF and other serializations (again as per the RDF WG draft charter)

That is correct. The profile mechanism has caught the attention of the RDF community at large and may end up being used. That being said one could argue that the profile mechanism is simply a syntactic sugar and may not have to be present in the triple store!

> 
> The reason all of these items are in the initial draft of the API, is to ensure that the API is both backwards and forwards compatible, inclusive rather than exclusive - if it's later agreed that exceptions should be thrown in places or some of these interfaces moved out to a note, then at least we know that the API has been designed with these considerations in mind, and that it's compatible without having to immediately start work on a 1.1/2 API and potentially break BC or "hack" them on later.
> 
>> Why? Firstly, packaging something up and calling it an RDF API when it
>> goes significantly beyond the RDF API will irritate some people.
> 
> Well, tbh they can still implement the API and just impose the arbitrary restrictions themselves, many are imposed by serializations anyway - nothing is actually lost other than a "conformance badge".
> 
>> Secondly, it will make it difficult to implement the RDF API as a layer
>> on top of existing RDF toolkits.
> 
> As per above, it can still be implemented, just with some per implementation restrictions, and some scope to grow in to.
> 
> I'm by no means saying that this is the case, just that it's one of many possible approaches.
> 
>> Notation 3 support should be stripped out and worked on as an extension
>> to the RDF API separate document. A Notation 3 API extension is almost
>> certainly beyond the RDFa Working Group's current charter, but that is
>> fine as it doesn't stop RDFa Working Group members from working on this
>> extension outside of RDFa WG time. The Notation 3 API extension should
>> probably not be Rec track, at least not until some time when Notation 3
>> itself is.
>> The only nod towards Notation 3 that the RDF API itself should offer is
>> to avoid making that extension difficult. In other words, don't add
>> normative requirements that would preclude a conformant RDF API
>> implementation from also supporting Notation 3.
>> In particular I'd like to see the following changes made to the RDF API:
>> 1. Drop the GraphLiteral interface.
> 
> Any particular reason why it needs dropped now? we could always factor it in to a different note or remove it should the RDF WG not define RDF literals.

Another possibility is to avoid the suggestive name. We have fought with this issue when setting up the charter, and the current charter is a bit vague (intentionally so). I can imagine that the final work would lead to two different notions, one more in direction of separate graphs and the others more in direction of, say, quoted graphs. I am not sure what term to use here, though.

Ivan

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