Re: RDF Interfaces - new draft

On 2 May 2011, at 17:10, Nathan <nathan@webr3.org> wrote:

> Ivan Herman wrote:
>> On May 2, 2011, at 15:52 , Nathan wrote:
>>> Ivan Herman wrote:
>>>> - 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...
> 
> toNative?

Sort of... it is fine for a datatype, but it is strange for, say, a bnode...

'name' for value and leave the toValue()?


> 
>>>> - 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 implement
> ations 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?
> 
> To give some perspective, typically we could see:
> 
> 2nd level library implementers as including which elements they need from different open source implementations, then building an end user jquery like API on top of the components. For this end users will need to read the documentation, whilst the library implementer will be using different components / implementations and simply including what they need.
> 
> Advanced users will likely assemble an library for the job, include('environment'); include('lib/foo/rdf.parser'); include('lib/bar/x-parsers'); and call each one for the job on an on demand basis, perhaps even having multiple different implementations of each parser.
> 
> Parser/Serializer implementers won't even necessarily know which implementation of the RDF Interfaces there component will be used with, if any, hence why it's injected in to the constructor.
> 
> So I guess my question would be, how does an included DataParser or DataSerializer even find the RDFEnvironment to augment it with new methods, and further can it augment it, or is the class definition locked?
> 
> 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?
> 
> Perhaps some factory registration methods, that's if we can standardize a universal way to access the RDFEnvironment and come up with a registry of unique parser/serializer names, taking in to account multiple implementations of each?
> 
> Best,
> 
> Nathan
>

Received on Monday, 2 May 2011 16:53:56 UTC