[Versa] Issue 3
Michael Olson
Mike.Olson at fourthought.com
Sun Aug 14 22:49:41 MDT 2005
On Aug 13, 2005, at 7:29 AM, Uche Ogbuji wrote:
> On Sat, 2005-08-13 at 00:41 -0400, Chimezie Ogbuji wrote:
>> Along the lines of promoting subjects to first class Versa datatypes
>> (and the problem of such a major change), I had the idea that perhaps
>> you could maintain the current infrastructure but have a way to
>> extract / project statements as a set of 3 item lists
>> (subject,predicate,object) and have 3 functions for extracting the
>> parts of the lists:
>>
>> subjects(x) => map(x,'.[1]')
>> predicate(x) => map(x,'.[2]')
>> objects(x) => map(x,'.[3]')
>>
>> Consider a 'Statement Pattern' expression (different from a traversal
>> operator) that allows you to extract statements (as a set of 3 item
>> lists):
>>
>> {SPF SPF SPF} => set(list(s1,p1,o1),list(s2,p2,o2),list(s3,p3,o3),...)
>>
>> where SPF (statement pattern filter) is either an expression which is
>> converted to a list which serves as a filter against the corresponding
>> components (subject/predicate/object) of candidate statements.
>> Statements are included only if the corresponding part is a member of
>> the list. SPF can also be '*' in which case it is a wildcard and no
>> filtering is done for those components.
>>
>> So:
>> A - B -> * becomes objects({A B *})
>> all() |- B -> eq('foo') becomes objects({* B 'foo'})
>>
>> Such patterns can do everything traversal operators do now in addition
>> to address the original *issue* of returning predicates. My use of {
>> .. } clashes with my earlier suggestion to use them as existential
>> placeholders, but I'm quickly running out of grouping characters that
>> are not used :)
>>
>> This is just an idea to allow statements to be visible to the Versa
>> data core w/out breaking it's current infrastructure but perhaps
>> Uche's example use o filter to retrieve the properties on a resource
>> with a particular value solves the original problem and this isn't so
>> neccessary.
>>
>> Just some food for thought
>
> I do think that for Versa 2.0 we should make statements first class.
> Your syntax suggestion is similar to what I was trying to get at
> earlier, but I think you solved my semantic problem for me with {SPF
> SPF
> SPF}. Each SPF would be resolved into a pattern as follows:
>
> * If the SPF is *, it is resolved into a pattern that matches anything
> * If the SPF is a primitive scalar, datatyped literal or resource, it
> is
> resolved into a pattern that must match that string or resource exactly
> * If the SPF is a list or set, it is resolved into a pattern that must
> match one of the items in the list or set exactly
> * If the SPF is a function, f, then it is a special filtering function
> pattern, and the pattern is equivalent to the resulting list from
> filter(<all possible values>, f). (This means that the function must
> take each item to be filtered as its first parameter)
>
> As you say in your examples:
>
> A - B -> * becomes objects({A B *})
> all() |- B -> eq('foo') becomes objects({* B 'foo'})
I wonder what we need to change so much syntactically?
Why can't "all() - B -> we("'foo') return statements. Then use
"object(expression)" or "subject (expression)" to filter the results.
As far is "SPF"s. Isn't "all()" equivalent to "*" already? we already
support #2 which is literals and scalars. We support #4 for objects
now, it would just be a matter of supporting them for subjects and
predicates. I think #3 is a great addition as well.
qname("foo",union("a",b")) - map(properties(<rdfs:class>),{. -
rdfs:subPropertyOf *}), gt("1"^^"xsd:int")
So, using many new ideas
"Give me, all _statements_ where the subject us the URI from the
expanded prefix "foo" and the local name of "a" or "b". The predicate
is one of the subProperties of any property that is used on the
resource "rdfs:Class" and the object is the integer value greater then
one.
>
> I wonder whether this is taking us back to the limited triple-based API
> that we'd been hoping to get away from in creating Versa. I'd have to
> think through some more complex examples to decide for myself.
>
I've actually come full circle on this. At one time I was in the
avoid triples camp. It turns out, for me atleast, that "little bit of
extra time in the query" is greatly overshadowed by the cost of
supporting interfaces for all of the different results types. Besides
"statement" results, two that I've found that fo greatly improve
performance are the idea of a "count" results (ie, number of statements
that match these criteria) and a "contains" results ie (boolean of is
there at least one statement that matches). Performance wise, the last
being much more important that the first. I do a lot of
"isInstance(resource,type)" type method calls where my only concern is
there is one statement that matches.
Mike
>
> --
> Uche Ogbuji Fourthought, Inc.
> http://uche.ogbuji.net http://fourthought.com
> http://copia.ogbuji.net http://4Suite.org
> Use CSS to display XML, part 2 -
> http://www-128.ibm.com/developerworks/edu/x-dw-x-xmlcss2-i.html
> XML Output with 4Suite & Amara -
> http://www.xml.com/pub/a/2005/04/20/py-xml.html
> Use XSLT to prepare XML for import into OpenOffice Calc -
> http://www.ibm.com/developerworks/xml/library/x-oocalc/
> Schema standardization for top-down semantic transparency -
> http://www-128.ibm.com/developerworks/xml/library/x-think31.html
>
> _______________________________________________
> Versa mailing list
> Versa at lists.fourthought.com
> http://lists.fourthought.com/mailman/listinfo/versa
>
------------------------------------------------------------------------
-----------------
Mike Olson Principal
Consultant
mike.olson at fourthought.com +1 720 253 4662
Fourthought, Inc.
http://Fourthought.com
PO Box 270590, http://4Suite.org
Louisville, CO 80027-5009, USA
XML strategy, XML tools, knowledge management
More information about the Versa
mailing list