Values and terms.

[Andy Seaborne <an...@apache.org>]

Paul,

(This is technical input so I changed the subject line.)

commonsrdf is trying not to be "yet another toolkit".

Having a small, focused core is part of that so the minimal conversion 
point is small.

Is there a way to make this a separate piece of functionality on top of 
the core?  Maybe something for terms <-> values.

Incidently:

   https://github.com/afs/xsd4ld

which is just XSD for linked data.  No RDF toolkit dependencies.

(I did wonder about a companion XSD library by ripping out/off the ARQ 
xsd function support and removing it's tie to Jena - it already goes 
through "NodeValue" which is value-focued, rather than term-focued.)

	Andy

On 03/11/15 17:33, Paul Houle wrote:
> I like that the current implementation is simple and correct,  but I think
> the constant conversion between primitive types and strings if you actually
> tried to use this would (i) hurt speed,  and (ii) hurt the perception of
> speed.
>
> Connected with that is this need to deal with type conversion when you put
> data into RDF,  a subject that can get pretty awkward.  Jena gets it
> half-right but I prototyped something that is a lot more fun to work with
> at:
>
> https://github.com/paulhoule/incubator-commonsrdf/blob/master/api/src/test/java/org/apache/commons/rdf/api/AbstractRDFTermFactoryTest.java
>
> look at the tests towards the end of that file to see what the API looks
> like.
>
> Another thing my version does is add an "RDF" superinterface that covers
> most of the other interfaces and adds a reference to a Context object that
> in turn points back to an RDFContext (which used to be called the
> RDFTermFactory.)
>
> This lets you build value-added implementations that do all sorts of
> things.  The storage/performance cost can be brought to nothing by using a
> static but you could support things like the Jena model that let you
> interact with the graph in a direct way.  Similarly you could make the
> RDFContext configurable so if you have strong feelings about how it should
> behave in corner cases it can be made so.
>
> I'd be inclined to go another step further and add a generic parameter to
> RDF and have that be some subclass of RDFContext.
>
> Anyway if there was some serious review of this and any objections about
> details can be sorted out I can imagine proposing this as the next draft.
>
>
>
>
>
>
>
>
>
>
> On Tue, Nov 3, 2015 at 11:38 AM, Rob Vesse <rv...@dotnetrdf.org> wrote:
>
>> Folks
>>
>> I've seen very little traffic for the last few months, while this is not
>> necessarily an issue in the short term it seems to reflect a general long
>> term trend of lack of activity after the initial flurry that occurred when
>> the podling was first established and put together the initial release.
>> I've seen a bit of discussion around adoption in other communities but
>> nothing that appears to have yet gone anywhere.
>>
>> I am concerned that there is perhaps no longer a viable community around
>> this podling especially given the withdrawal of several folks and strong
>> objections to technical direction from others.  The technical direction is
>> not really a problem since the ASF encourages, allows and promotes
>> competing
>> technological approaches and the Foundation itself stays out of the
>> technical direction of projects.  However if there is no longer a viable
>> community here then at some point you have to start thinking about other
>> options e.g. retirement or leaving the Incubator for another venue I.e.
>> returning to GitHub
>>
>> Do folks still think that it is possible to build something that will
>> actually be adopted by the other involved communities?  Do people still
>> think this project has/can build the necessary momentum to move forwards
>> towards graduation in the long term?
>>
>> Rob
>>
>>
>>
>
>

Re: Values and terms.

[Paul Houle <on...@gmail.com>]

I like the thinking behind the XSD types implementation.  Over time I have
come to see that there are two problems in data format conversion, text
analysis,  etc.

(i) syntactic -- extracting the relationships that are implicit in
concepts,  and
(ii) semantic -- understanding references to entities ("Walt Disney
Company") as well as literals (maybe even "four" or "last month")

In my mind the fundamental thing in RDF is the node,  not the triple.

Anyhow,  in my version of the interfaces,  default methods are used to
implement literal conversions so the work to implement a working
implementation is the same as in 1.0.   If you want better performance,
 you can then implement the full methods.

Performance,  both real and imagined,  really does matter,  and I think
ergonomics matter even more.

>From the viewpoint of marketing RDF I am thinking we need to take a cue
from JSON,  which has been successful because it has mirrored the common
data structures used in dynamic languages.

I see people struggling with SPARQL despite how simple it is,  and when it
comes to dealing with nodes and triples correct and efficient code should
flow off your fingertips.

>From my viewpoint it does not matter at all if we get another generation of
RDF tools unless real people can use them.

On Thu, Nov 5, 2015 at 10:05 AM, Andy Seaborne <an...@apache.org> wrote:

> Paul,
>
> (This is technical input so I changed the subject line.)
>
> commonsrdf is trying not to be "yet another toolkit".
>
> Having a small, focused core is part of that so the minimal conversion
> point is small.
>
> Is there a way to make this a separate piece of functionality on top of
> the core?  Maybe something for terms <-> values.
>
> Incidently:
>
>   https://github.com/afs/xsd4ld
>
> which is just XSD for linked data.  No RDF toolkit dependencies.
>
> (I did wonder about a companion XSD library by ripping out/off the ARQ xsd
> function support and removing it's tie to Jena - it already goes through
> "NodeValue" which is value-focued, rather than term-focued.)
>
>         Andy
>
> On 03/11/15 17:33, Paul Houle wrote:
>
>> I like that the current implementation is simple and correct,  but I think
>> the constant conversion between primitive types and strings if you
>> actually
>> tried to use this would (i) hurt speed,  and (ii) hurt the perception of
>> speed.
>>
>> Connected with that is this need to deal with type conversion when you put
>> data into RDF,  a subject that can get pretty awkward.  Jena gets it
>> half-right but I prototyped something that is a lot more fun to work with
>> at:
>>
>>
>> https://github.com/paulhoule/incubator-commonsrdf/blob/master/api/src/test/java/org/apache/commons/rdf/api/AbstractRDFTermFactoryTest.java
>>
>> look at the tests towards the end of that file to see what the API looks
>> like.
>>
>> Another thing my version does is add an "RDF" superinterface that covers
>> most of the other interfaces and adds a reference to a Context object that
>> in turn points back to an RDFContext (which used to be called the
>> RDFTermFactory.)
>>
>> This lets you build value-added implementations that do all sorts of
>> things.  The storage/performance cost can be brought to nothing by using a
>> static but you could support things like the Jena model that let you
>> interact with the graph in a direct way.  Similarly you could make the
>> RDFContext configurable so if you have strong feelings about how it should
>> behave in corner cases it can be made so.
>>
>> I'd be inclined to go another step further and add a generic parameter to
>> RDF and have that be some subclass of RDFContext.
>>
>> Anyway if there was some serious review of this and any objections about
>> details can be sorted out I can imagine proposing this as the next draft.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Nov 3, 2015 at 11:38 AM, Rob Vesse <rv...@dotnetrdf.org> wrote:
>>
>> Folks
>>>
>>> I've seen very little traffic for the last few months, while this is not
>>> necessarily an issue in the short term it seems to reflect a general long
>>> term trend of lack of activity after the initial flurry that occurred
>>> when
>>> the podling was first established and put together the initial release.
>>> I've seen a bit of discussion around adoption in other communities but
>>> nothing that appears to have yet gone anywhere.
>>>
>>> I am concerned that there is perhaps no longer a viable community around
>>> this podling especially given the withdrawal of several folks and strong
>>> objections to technical direction from others.  The technical direction
>>> is
>>> not really a problem since the ASF encourages, allows and promotes
>>> competing
>>> technological approaches and the Foundation itself stays out of the
>>> technical direction of projects.  However if there is no longer a viable
>>> community here then at some point you have to start thinking about other
>>> options e.g. retirement or leaving the Incubator for another venue I.e.
>>> returning to GitHub
>>>
>>> Do folks still think that it is possible to build something that will
>>> actually be adopted by the other involved communities?  Do people still
>>> think this project has/can build the necessary momentum to move forwards
>>> towards graduation in the long term?
>>>
>>> Rob
>>>
>>>
>>>
>>>
>>
>>
>


-- 
Paul Houle

*Applying Schemas for Natural Language Processing, Distributed Systems,
Classification and Text Mining and Data Lakes*

(607) 539 6254    paul.houle on Skype   ontology2@gmail.com

:BaseKB -- Query Freebase Data With SPARQL
http://basekb.com/gold/

Legal Entity Identifier Lookup
https://legalentityidentifier.info/lei/lookup/
<http://legalentityidentifier.info/lei/lookup/>

Join our Data Lakes group on LinkedIn
https://www.linkedin.com/grp/home?gid=8267275