Re: RDFa API comments from TimBL

On 2010-10 -05, at 11:27, Ivan Herman wrote:

> 
> On Oct 5, 2010, at 16:52 , Nathan wrote:
> 
>> Ivan Herman wrote:
>>> Nathan,
>>> can you tell me what exactly the IndexedFormula and the IndexedDataStore does?
>> 
>> It would only require IndexedDataStore, which would/could add the following new functionality (Tim if you have anything specific I've missed please do say):
>> 
>> indexed access to the triple as subject[predicate][object],

The way a given triple store indexes its data is an optimization in fact,
and to first order is hidden internally.
((The IndexedFormula class keeps 3 lists for all x of where x occurs as a subject, pred, or object, and one list of statements which were loaded from resource x (if any). this is an implementation optimization.))


> 
> 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?
> 
>> and also indexes for each s/p/o `for( triple in store.subjects[subject] )` or via methods
>> 
> 
> I am not sure I understand that.
> 
>> 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...

The (complicated RDF meets DOM) RDFa API should be designed as an extension to the (simple clean RDF model only)  RDF API.


If the RDFa is designed first, then the design will be terrible as you can't design the extension before that extended.
Because any RDFa script will want to have the basic RDF API.


> 
>> 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.
> 
>> - any() which is the same as above but returns the first match (existential)
>> 
> 
> right
> 
>> support smushing
> 
> meaning?

This is an optional feature the tabulator needs.  It doesn't affect the basic interface.
Any two nodes which are declared or found to be owl:sameAs from IFP or FP processing are "smushed" into one node.
This is essential for lined data -- without it stuff often doesn't link.

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

Canonicalize URI compare, and also check whether smushed to same thing.
Or for literal compare all fields.

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

When it has been smushed, it will end up with >1 URI


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


No, it is an event listener for additions to the store, not a query.
You register a listener for when a triple is added to the store with a given predicate.
These are bells and whistles the tabulator needs.

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

Exactly.

That's why I made a version of the spec with a modified section 3.1.2
to show what the tabulator rdflib.js library API looks like.
It is similar.

The way the namespaces work I think is nice,

You say foaf =  $rdf.Namespace("http://....");
data.add(me, foaf('name'), you);

Now I'd make it "ns" rather than Namespace in the spirit of making it all fairly compact.

And the each() and any() where you use a missing parameter as a wildcard.

	friends = data.each(me, foaf('name'))  // People I know
	incoming = data.each(undefined, foaf('name'), me); // People who know me

Tim

PS:  Extra optional stuff:
	The tabulator also tracks provenance in a 4th component so  you can say

	friends = data.each(me, foaf('name'),undefined, myFoafFile)  // People my foaf file says I know
	why = data.each(you, foaf('name'),me)  // Document which says you know me


> 
> Thanks!
> 
> Ivan
> 
> 
> 
>> 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
> 
> 
> 
> 
>

Received on Tuesday, 5 October 2010 21:16:46 UTC