Re: RDFa API comments from TimBL

Ivan Herman wrote:
> On Oct 5, 2010, at 16:52 , Nathan wrote:
>> indexed access to the triple as subject[predicate][object],
> 
> I have no idea how complicated that is in Javascript. But I can see the value. Would subject[predicate] give back an array of possible objects?

It's much easier in Javascript (much is an understatement) - essentially 
the full graph is turned in to an object of this structure

{
   ":nathan": {
     "foaf:name": ["nathan"],
     "foaf:knows": ["manu", "ivan", "mark"]
   }
   "subject2"...
}

so let's say we put all this in a property .graph, then you could do:
   var nathan = store.graph[":nathan"];
and `nathan` would contain an object with all the properties as 
properties, and each value as an array of objects.

likewise if you did store.graph[":nathan"]["foaf:knows"] you'd get an 
array of ["manu", "ivan", "mark"] back - this should work in other 
languages too, certainly does in PHP and the likes.

we could also this behind and interface and add a toIndex() method 
returning this structure, and/or add methods like 
getIndexBySubject("nathan") to do the same, lots of options but having a 
graph in a structure like this is so much easier to work with.

>> and also indexes for each s/p/o `for( triple in store.subjects[subject] )` or via methods
> 
> I am not sure I understand that.

meaning store.predicates["foaf:name"] would hold a set of all triples 
which have foaf:name as the property, the index is needed behind the 
scenes (normally) to provide fast (indexed) lookups, and it can be nice 
to expose - however it can easily be exposed via other means (filtering 
etc).

>> ability to remove triples
> 
> With my RDFLib background: of course. But I really wonder whether we are not going beyond the RDFa API level here. That was what I said in my previous mail...

Unsure, seems an easy hit but not up to me to decide, if an official 
"RDF API" never gets specified (or not for a long time) would we be 
kicking ourselves? also this spec has pretty much everything needed to 
be an RDF API except this one interface.. and further, would a dedicated 
RDF API not be defined in terms of WebIDL and either have to match or 
conflict with the (then widely deployed) RDFa API?

I guess what I'm asking is two fold - what's left for an RDF API to 
define? and, is it realistic to define a new "RDF API" at whatever time 
when the RDFa API is already out there, deployed, standardized, relied 
upon (and notably missing this extra bit).

>> each(s,p,o) where given any two arguments, returns an array of the third, so given each(":me", "foaf:knows", null) would return back an array objects / URIs.
> 
> Isn't it true that the current gives you that and more already? Isn't it what the pattern in filter does? Although the syntax is indeed a little bit convoluted; my RDFLib instinct would ask for something simpler like that.

nope, it's different to filter in that given each(":me", "foaf:knows", 
null) this method will return back the objects ["manu", "ivan", "mark"] 
rather than a sequence of triples.

>> support smushing

support for owl:sameAs and inferring owl:sameAs based on inverse 
functional properties

>> , adds method to check if two uris are the "same thing",
> 
> same as equality of strings? or equality of URIs?

URIs, as above

>> adds method to get all uri's by which a thing is known by
> 
> Meaning?

all the link:uri's of a thing

>> registerPropertyAction, this registers a function which is run against all triples which have a certain property - may not sound much but it's a highly versatile and efficient way of programming.
> 
> Ah. That is a combination of forEach with an extra filter I guess...

~ish, when you first register a property action it runs against 
everything in the store (foreach w/ filter), but then for each new 
triple added it runs as the triple is added - essentially it works like 
custom event listeners waiting for triples of a certain kind to be added

>> In addition, it adds a few easy access methods such as add(s,p,o) where each property is a string and
>>
>> statementsMatching(s,p,o), which returns all statements matching a pattern (where each of s,p,o are optional and are strings)
> 
> sound like the query

yup similar, easier to call and work with though, IndexedFormula in 
tabulator has a lot of short proxy methods like this which make life 
somewhat easier when your using the API frequently - however all the 
functionality listed after "In addition," above is already in the RDFa 
API, just without additional convenience methods.

>> - anyStatementMatching() which is the same as above but returns the first match (existential)
>>
>> I'd be more than happy to put together something more solid in IDL with notes if you like.
> 
> So, on a cursory look, what this shows me is that the difference between those methods and the current ones are not fundamentally different. So what would be good is to reconcile these two, rather than creating a separate one...

Did you see.. 
http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Sep/0122.html 
which simplifies the API somewhat so that DataStore is essentially 
aligned with a native Array in ECMAScript, as in, extremely light, a 
sequence<RDFTriple>, designed to be easy to use and thrown between 
parsers/serializers filtered and forEach'd, whereas the above described 
is more of a "static" store with a heavier implementation for full on 
linked-data application coding, hiding optimized methods for working 
with larger sets of triples and so forth.

That said, they could align.. should I put together 2-3 sets of IDL, one 
with them separate, and another with a merged do-it-all store?

Cheers,

Nathan

Received on Tuesday, 5 October 2010 16:31:18 UTC