Re: RDF Interfaces - new draft

On May 2, 2011, at 15:52 , Nathan wrote:

> Ivan Herman wrote:
>> Yay:-)
> 
> Hi Ivan - thanks for taking the time!
> 
>> I have a few minor comments below, but those can be taken care of later. The document can go, in my view, to a FPWD right away:-)
>> My minor issues:
>> - I see you have the 'value' and the 'valueOf()' for RDF Nodes. After having read the interface specification it is clear that they are different (primarily for Literals). But I am not sure using essentially the same English term is good here. I am not 100% sure what to replace these terms with; maybe the 'value' attribute should be replaced by 'id'? Nay, that is not really good either...:-( The RDF Semantics uses the word 'denotation' for, well, the string value of a URI, but that seems to be a mouthful for that...
>> In any case, _before_ reading the details I was certainly messed up a bit by having these two together.
> 
> Okay, will have a think and propose some wording or a different name for the attrib or method.

The wording in general is fine imho. Just a different name for the attribute or the method...

> 
>> - In 2.4.1 it says:
>> "The following shows an example set of common TripleFilters exposed on a filter attribute of RDFEnvironment:"
>> referring to rdf.filters.s and the like. It is not clear from the text, however, whether it is _required_ for an RDFEnvironment to implement those, or whether they are a typical set of filters that an RDFEnvironment may implement. I am not against the former, actually, but then we should list those as part of the RDFEnvironment specification.
> 
> The latter, an example, will make that clearer.

o.k.

> 
>> - This is more a question than a bug: how does a programmer get to a parser? In your last example the 'turtle' parser is just magically there; how does that work in practice. Does it mean that, somehow, a library has to provide me with an implementation of the RDFInterface and a set of parsers whose names I have to find from the library's documentation?
>> I would have expected to find, for example, a list of available parsers and serializers in the RDFEnvironment and I could start from there. Or, alternatively, have a method like
>> getParser(format)
>> where format identifies the serialization format and the rdf interface returns, eg, the parser instance. The same with a serializer, of course.
> 
> In section 4.1 we have:
> 
> "Parser and Serializer implementors should provide relevant parse, process or serialize methods on the RDF Environment interface for their implementations. For example a Turtle parser SHOULD augment RDFEnvironment with parseTurtle and processTurtle methods which accept a String toparse argument, whilst an RDFa parser SHOULD augment RDFEnvironment with a parseRDFa method which accepts a Document argument."
> 
> The main reason for this (and the SHOULDs) is that it's a modular API with dependency injection, so people may well be mixing and matching components, instantiating parsers as new TurtleParser(rdf); and including them as needed, rather than having a large code base always loaded (and forcing standardized names for each standardized and community created serialization), whereas in other scenarios they may just be using a full always present library and 2nd level API which mandates the presence of certain parsers. Essentially, there are so many different ways that people may have these things set up, including gleaning RDF from non RDF resources, that one didn't want to push down the must register everything line. Each interface can have several implementations, for example a persistent graph interface, an indexed one, an entailment regime aware one, the same goes for parsers, serializers and other components, so for now I hoped that focussing on making sure these implementations and components are interoperable, rather than defining how they must all be accessed, would perhaps be enough.

First of all, we should push out the FPWD as it is, so this specific issue should not be a show stopper... My question is for the next version...

My worry is as follows: how can I find out, in a program, what parsers are available to me? My reading of what you say is that the only way is to look at the library's documentation. Is there a clever way of combining what you say with some sort of run-time trick to find out what parsers or serializers I can use, ie, what serialization formats are available?

Ivan


> 
> Best,
> 
> Nathan
> 
>> On May 2, 2011, at 01:21 , Nathan wrote:
>>> Hi all,
>>> 
>>> Just a quick note to say that I think I'm done with the RDF Interfaces specification for now, and it's ready for a sanity check before preparing for FPWD.
>>> 
>>> http://www.w3.org/2010/02/rdfa/sources/rdf-interfaces/
>>> 
>>> Since the last version there are a number of changes, I've fully rewritten the definition of Literal to reflect current conversations, GraphLiteral/TripleSet is gone, a couple of changes to the Graph interface ('the' is gone, 'match' is added, 'removeMatches' is added), RDFNode equality is redefined and clarified, a 'toValue' method is added to RDFNode (particularly for working with Literals), lot's of clarifications and cleanups to the text, issues and notes added etc.
>>> 
>>> Please do have a read and let me know.
>>> 
>>> 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
> 


----
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 Monday, 2 May 2011 13:59:30 UTC