[Versa] Versa issue: subgraph primitives?

[Michael Olson]

On Sep 8, 2005, at 9:00 PM, Chimezie Ogbuji wrote:

> A few clarifying questions about the proposed { .. query .. } syntax.
> So, how do the following queries below differ?:
>
> I.    type(rss:item) |- dc:creator -> <mailto:foo at yahoo.com>
>
> II.   { type(rss:item) |- dc:creator -> <mailto:foo at yahoo.com> }
>
> Does the first return the subjects of matching statements only (the
> rss:item's created by mailto:foo at yahoo.com), where the second one
> returns a sub-graph consisting of all statements made about that
> subject?

I think they both return a list of subjects that match.  The difference  
being that the second would result with in an error or an empty result  
if used as a scope.  You would need to rewrite the second to be  
(assuming a result type optional argument to the filter function)

{  
filter(type(rss:item),dc:creator,<mailto:foo at yahoo.com,versa:statement)  
}

>
> And if so, what if the forward traversal operator was used instead of
> the filter?:
>
> { type(rss:item) - rss:title -> contains('4Suite') }
>

Same

> Would that also return the matching statements only (i.e., all
> statements about rss:items with a title that contained '4Suite')  ?
> Would that render the distinction between forward (or backward)
> operators and filters irrelevant within context expressions, since the
> result is a list of statements not the specific parts?
>
> So, if I wanted to find the authors of all rss:items with a title that
> contained the string '4Suite', I could write either:
>
> { type(rss:item) - rss:title -> contains('4Suite') } . - dc:creator ->  
> *
>
> or
>
> { type(rss:item) |- rss:title -> contains('4Suite') } . - dc:creator  
> -> *
>

I don't think so.  I was thinking more along the lines I mention above,  
a scope is a subgraph so it needs to be a list/set of statements.

>
> Also, I'm still not quite sure how the need to query within a context
> by a given 'name' (not neccessarily one assigned to a variable within
> the evaluation of the query) is covered in the suggested context query
> syntax.  The specific use case:
>
> I want to query across the entire underlying model, find a resource,
> identify the name of the context it is associated with in the
> underlying graph (which could be - by definition - the set of contexts
> of all statements made about the resource), and invoke a follow-up
> query within that context alone.
>

So, if I follow, create a scope the is "all statements about a  
resource" then issue a sub query on that set?  If so, using your  
example, then it would be (with a function called statements that us  
designed just to produce a sub graph)

subgraph myresource =  
statements(type(rss:item),rss:title,contains('4Suite')

{myresource} . - dc:creator -> *

would give all creators of rss:item type resource with a title that  
contains ('4Suite')

I think of this as a pretty easy example though that could be done as  
simply with out sub graphs, here may be a better one:

Given the merger of two ontologies (where all resource properly use the  
isDefinedBy property), I would like to find duplicates rdf:values  
between the ontologies.  Not with in each (beacuse that should have  
been known????)  So if we have something like

Ontology 1
------
resourcea -- rdf:value  --> v1
resourceb -- rdf:value --> v2
resourcec -- rdf:value --> v1

Ontology2
------
resourcex -- rdf:value --> v3
resourcey -- rdf:value --> v1
resourcez -- rdf:value --> v3


I would like to see that between the two ontologies we have a conflict  
between resourcea and resource z (resourcea,resourcec conflict is  
ignored because they are from the same ontology and not part of the  
original query, same with the conflict of resourcex and resource z)

The query I would use would be

subgraph o1 = statements ( all() - rdfs:isDefiniedBy -> <Ontology  
1>,rdf:value,*);
subgraph o2 = statements ( all() - rdfs:isDefiniedBy -> <Ontology  
2>,rdf:value,*);
list( {o1}  all() |- * -> {o2}ground(.),
             {o2} all() |- * -> {o1}ground(.) )

would give me a result of
[ [resourcea], [resourcey] ]

Slightly contrived but might help get my thought across.

Mike

>
> Chimezie
> _______________________________________________
> 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