extending the linkeddata class

[scott farrar]

HI Bill

Related to the problem of deriving a method at runtime, I've opted for another solution.  First, 'svn up' your copy of ontology/LinkedData.py. At the bottom of the file, I present the solution. Basically, I extended the LinkedData class w. a Termset class. I then created a method called get 'getTermMeaning' which will enable you to load a termset graph, and then query it. The method contains sparql code.

Here's how to use the code (also in LinkedData.py):


  mydata=Termset(u'http://purl.org/linguistics/data/mydata.rdf')

    mydata.parse(ELTK_HOME+'/examples/outputfiles/LeipzigTermset.rdf')

    print mydata.getTermMeaning('subjunctive')

    print mydata.getTermMeaning('

I think is a general solution of when we need to work with specific data types like 'termset' that are represented as graphs. We could also have Lexicon and create methods like 'showLexemes' etc.

Scott

[W.P. McNeill]

The getTermMeaning() method is easy to incorporate into the code I have been writing, and hiding SPARQL queries in function calls seems like a good design decision.  I think this gives me what I need to finish writing the SignListReader.

Is this going to be a general enough solution for the whole project?  For example, say we get some LinguisticSign instance x out of GOLD.  Are we going to be able to call the function:

>>> x.hasMeaning

--
W.P. McNeill
http://staff.washington.edu/billmcn/index.shtml
Sent from Seattle, WA, United States

[scott farrar]

Hi Bill

Yes, I think this will be a general solution but only for linguistic data types  that are whole graphs: Termset, Lexicon, IGT, etc. But regarding specific sign individuals (Graph nodes), I'm not sure if this makes sense. For all sign instances, we're back to the old problem of generating methods on the fly for each instance.

Scott

[W.P. McNeill]

Do we actually need to generate arbitrary Python code on the fly for
the properties of individual Graph nodes?

Say we have a graph with nodes X,Y,Z and edges a and b configured like
so:

Y <-a-- X --b-> Z

As I understand it, the more general problem for the OWL-to-Python-OOP
mapping problem is that we want to be able to create an instance of X
called x and then deference its properties like so:

>> x.a # returns an instance of Y
>> x.b # returns an instance of Z

Would we need to create Python code at runtime to do this, or could we
just specify property values at runtime? (I don't know the answer;
it's been a while since I've looked at properties.)

On Aug 13, 3:00 pm, scott farrar <sofar...@gmail.com> wrote:
> Hi Bill
>
> Yes, I think this will be a general solution but only for linguistic data
> types  that are whole graphs: Termset, Lexicon, IGT, etc. But regarding
> specific sign individuals (Graph nodes), I'm not sure if this makes sense.
> For all sign instances, we're back to the old problem of generating methods
> on the fly for each instance.
>
> Scott
>
>
>
> On Thu, Aug 13, 2009 at 2:44 PM, W.P. McNeill <bill...@gmail.com> wrote:
> > The getTermMeaning() method is easy to incorporate into the code I have
> > been writing, and hiding SPARQL queries in function calls seems like a good
> > design decision.  I think this gives me what I need to finish writing the
> > SignListReader.
> > Is this going to be a general enough solution for the whole project?  For
> > example, say we get some LinguisticSign instance x out of GOLD.  Are we
> > going to be able to call the function:
>
> >  >>> x.hasMeaning
>

[scott farrar]

OH right. Properties instead of methods. Thanks for reminding me. I'll try and get something this evening. So, would it be acceptable for X.hasMeaning to return a list? I say this because some individuals will have more than one "subject" for the predicate, e.g., consdier the hasProperty relation (meaning " has linguistic feature":

X hasProperty Y
X hasProperty Z

So X.hasMeaning will return [Y,Z]

And if so, then do we want singleton lists for X's with only one hasProperty relation?

[W.P. McNeill]

Since multiple edges originating from the same node may have the same label, it makes sense to me to have the property return a list of target nodes as you suggest below.  And yes, we should return a one-item list in the case when there's just one edge with a particular name.

Also, I assume there is no a priori ordering that makes sense for all target nodes sharing an edge name, so the order in which target nodes will be returned in a property list should be undefined.

To give a concrete example, the graph:

X -a-> Y

X -a-> Z

X -b-> W

creates the following Python properties:

>> x.a # returns [Y,Z]

>> x.b # returns [W]

where the order of elements in the list returned by x.a may either be [Y,Z] or [Z,Y].

[scott farrar]

On Thu, Aug 13, 2009 at 3:34 PM, W.P. McNeill <bil...@gmail.com> wrote:

Since multiple edges originating from the same node may have the same label, it makes sense to me to have the property return a list of target nodes as you suggest below.  And yes, we should return a one-item list in the case when there's just one edge with a particular name.

Also, I assume there is no a priori ordering that makes sense for all target nodes sharing an edge name, so the order in which target nodes will be returned in a property list should be undefined.

Yes, that 's right. Order does  not matter.  So, should this be a set and not a list?

 

[W.P. McNeill]

Formally speaking it is a set, but for the purposes of implementation
a set is overkill. Just return a list and say in the documentation
that its order is undefined. This is what Python does for the keys
function of Dictionaries.

On Aug 13, 3:37 pm, scott farrar <sofar...@gmail.com> wrote:

> On Thu, Aug 13, 2009 at 3:34 PM, W.P. McNeill <bill...@gmail.com> wrote:
> > Since multiple edges originating from the same node may have the same
> > label, it makes sense to me to have the property return a list of target
> > nodes as you suggest below.  And yes, we should return a one-item list in
> > the case when there's just one edge with a particular name.
> > Also, I assume there is no a priori ordering that makes sense for all
> > target nodes sharing an edge name, so the order in which target nodes will
> > be returned in a property list should be undefined.
>
> Yes, that 's right. Order does  not matter.  So, should this be a set and
> not a list?
>
>
>
>
>
> > To give a concrete example, the graph:
>
> > X -a-> Y
> > X -a-> Z
> > X -b-> W
>
> > creates the following Python properties:
>
> > >> x.a # returns [Y,Z]
> > >> x.b # returns [W]
>
> > where the order of elements in the list returned by x.a may either be [Y,Z]
> > or [Z,Y].
>

> > On Thu, Aug 13, 2009 at 3:26 PM, scott farrar <sofar...@gmail.com> wrote:
>
> >> OH right. Properties instead of methods. Thanks for reminding me. I'll try
> >> and get something this evening. So, would it be acceptable for X.hasMeaning
> >> to return a list? I say this because some individuals will have more than
> >> one "subject" for the predicate, e.g., consdier the hasProperty relation
> >> (meaning " has linguistic feature":
>
> >> X hasProperty Y
> >> X hasProperty Z
>
> >> So X.hasMeaning will return [Y,Z]
>
> >> And if so, then do we want singleton lists for X's with only one
> >> hasProperty relation?
>