Storing 1-d, 2-d arrays

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Storing 1-d, 2-d arrays

Mahmouduss
Hello,

In my project, I have started using Owlready2. However, I'm noticing that I can't find a way to define and register an array of values (or matrices) as an attribute of a class (or data property). The documentation shows a limited types of data that a dataproperty can support but is there a way to overcome that ?

fyi, my array's dimension is about 400x1 and 400 x 400 for my matrix.

Thank you very much.
Reply | Threaded
Open this post in threaded view
|

Re: Storing 1-d, 2-d arrays

Jiba
Administrator
Hello,

Ontologies are not very adapted to the storage of matrices: they are better suited for graph-like data or networks. You may serialize your matrix in a string, but it will limit the ability of the ontology to reasons on the content of the matrix. Or you may create an ontological model of the matrix, e.g. a Matrix class with a Row and Col classes, and a Cell class. A Cell has a value, a row and a column, etc. But this will highly increase the volume of your data, and is inefficient in terms of storage.

You may also consider RDF list for the 1D array, however, it is RDF and not OWL, and thus not supported by Owlready currently.

Jiba
Reply | Threaded
Open this post in threaded view
|

Re: Storing 1-d, 2-d arrays

Mahmouduss
Hello,

Very clear response, I will see what I can do. In fact, I don't really need to reason over the matrices, I think I can store them elsewhere and keep only an "id" in the ontology to ensure the link.

Thank you very much.
Reply | Threaded
Open this post in threaded view
|

Re: Storing 1-d, 2-d arrays

phiofx

I have the same need (to store a limited amount of numerical data within an ontology) and the serialization into string is the "obvious" solution I was missing :-) Thanks for that. In fact connecting the dots with hindsight this seems to be quite a standard solution, for example in the SVG standard the storage of paths and other geometries is simply a sequence of pairs of numbers.

Reasoning with numerical array contents would probably not be a typical use case, but there could be other functionality that would make life easier working with mixed data and moving them seamlessly between owl <-> python. For example introduce a convention for a 'JSONString' data type that requires a valid json as input and maps immediately to a python object upon deserialization... Just some thoughts