Fwd: Re: The Ordered List Ontology
Bob Ferris
Apologies for cross postings - this is for these people, who aren't at
the lod/semantic-web mailing list.
Cheers,
Bob
-------- Original-Nachricht --------
Betreff: Re: The Ordered List Ontology
Weitersenden-Datum: Mon, 28 Jun 2010 11:59:02 +0000
Weitersenden-Von: publi...@w3.org
Datum: Mon, 28 Jun 2010 13:58:15 +0200
Von: Bob Ferris <za...@elbklang.net>
An: publi...@w3.org
CC: Linked Data community <publi...@w3.org>, Semantic Web
<semant...@w3.org>
Hi Graham,
thanks a lot for this suggestion. I spent some more time in making this
concept a bit more solid [1,2]. Here the features that I added/changed
in the v0.3 proposal (+ for added, ~for modified):
+ olo:next - to associate the next slot of a slot in an ordered list
~ olo:length - to enable a single length association to an ordered list
~ olo:length - rdfs:range xsd:positiveInteger (no empty lists!)
~ olo:index - to enable a single index association to a slot in an
ordered list
~ anonymous inverse property of olo:slot to rdfs:type
owl:FunctionalProperty
With that changes it should be possible
... to create a unique neighbourhood relation; the list ends if the slot
hasn't a neighbour (that means no is:next property is set)
... to associate a single index to a slot; however, this still not
prevents from inserting several slots with the same index
... to associate a single length to an ordered list
To model the unique relations for index and length I followed the
pattern from here[3].
I think, if the size of the ordered list is defined in its length, which
should be used by a rule for validation, why we need than another
property, which defines its max length (see also my thoughts about
practical application)?
I still believe that it isn't possible to guarantee full valid ordered
lists, without the use of some rules (only with the
rdf:first/rdf:next/rdf:nil pattern). However, rules are created for some
purpose, so why not use them (think practical here).
Another practical thought is, if something changes in the ordered list,
e.g. a new slot would be added, than the graph of the list will be
rewritten or a new one would be created (that depends on the used
revision mechanism).
Comments, suggestions, critics on the new proposal are very welcome.
Cheers,
Bob
[1]
http://motools.svn.sourceforge.net/viewvc/motools/orderedlistsonto/branches/orderedlistsonto_v03/rdf/orderedlistontology.n3
[2]
http://motools.svn.sourceforge.net/viewvc/motools/orderedlistsonto/branches/orderedlistsonto_v03/gfx/olo_-_orderedlist.gif
[3] http://www.w3.org/TR/2004/REC-owl-guide-20040210/#simpleCardinality
Am 28.06.2010 10:51, schrieb Graham Klyne:
> Bob,
>
> A desired feature that led to the current rdf:List structure is the
> ability to "close" a list - so some separate sub-graph can't "silently"
> add properties not in the original. Your pattern might allow this
> through additon of a "maxSlotIndex" property on "olo:OrderedList" (not
> suggesting this as a design, just an example).
>
> #g
> --
>
>
> Bob Ferris wrote:
>> Hello everybody,
>>
>> in a longer discussion in the Music Ontology mailing list about how to
>> model a playlist, Samer Abdallah came up with a very good proposal[1]
>> of modelling a sequence/ordered list (as recently also discussed at
>> RDFNext Workshop[2]) as semantic graph (in RDF).
>> So, here we go:
>>
>> - specification[3] (please also note the anonymous inverse properties)
>> - concepts and relations in a graphic[4]
>> - funky playlist example[5,6]
>>
>> Again, thanks a lot Samer Abdallah for that cool concept.
>> Comments, suggestions, critics are very welcome.
>>
>> Cheers,
>>
>>
>> Bob
>>
>> PS: its all OWL based ;) however, we could also downgrade the concept
>> on the basis of rdfs:class, if needed.
>>
>>
>>
>> [1]
>> http://groups.google.com/group/music-ontology-specification-group/msg/305a42362a1e4145
>>
>> [2] http://www.w3.org/2009/12/rdf-ws/slides/rdflist.pdf
>> [3]
>> http://motools.svn.sourceforge.net/viewvc/motools/orderedlistsonto/trunk/rdf/orderedlistontology.n3
>>
>> [4]
>> http://motools.svn.sourceforge.net/viewvc/motools/orderedlistsonto/trunk/gfx/olo_-_orderedlist.gif
>>
>> [5]
>> http://motools.svn.sourceforge.net/viewvc/motools/orderedlistsonto/trunk/examples/orderedlist_-_example.n3
>>
>> [6]
>> http://motools.svn.sourceforge.net/viewvc/motools/orderedlistsonto/trunk/gfx/olo_-_orderedlist_example.gif
>>
>>
>
>
--
--------------------BEGIN-OF-SIGNATURE--------------------
Bob Ferris
website: http://elbklang.net
e-mail: za...@elbklang.net
--------------------END-OF-SIGNATURE----------------------
Samer Abdallah
On 28 Jun 2010, at 13:03, Bob Ferris wrote:
Hi Bob, I have a few comments about this below..
> thanks a lot for this suggestion. I spent some more time in making this
> concept a bit more solid [1,2]. Here the features that I added/changed
> in the v0.3 proposal (+ for added, ~for modified):
>
> + olo:next - to associate the next slot of a slot in an ordered list
I'm wondering if this isn't redundant, given that it's derivable:
next(S1,S2) == exists Seq . has_slot(Seq,S1) & has_slot(Seq,S2)
& index(S1,N1) & index(S2,N2) & succ(N1,N2).
Are you proposing that olo:next be used in the raw representation
of RDF data, or that it be used as a short cut for writing queries?
I feel that, in choosing a representation based on numerically indexed
slots (basically, arrays), we've made our bed, as it were, and now have to
lie in it. And it's an iterative/for-loop style bed. If we wanted to do
recursive list style processing with 'next', as in LISP, Prolog etc,
then we should go with a recursive list model, like rdf:List, but with
without the OWL-related problems. Both approaches have their
uses so I wouldn't say one is better than the other.
However, perhaps I misunderstand the RDF 'idiom' - is it common
practice to define properties that can be logically derived from other
properties?
> ~ olo:length - to enable a single length association to an ordered list
> ~ olo:length - rdfs:range xsd:positiveInteger (no empty lists!)
I'm not sure about this - while an empty sequence might seem to be pointless,
for many recursively defined algorithms on recursive list data types, the
empty list is the natural state on which to terminate the recursion.
The new sequence model is not a recursive data type, so perhaps this
is not a valid concern, but if anyone wants to start defining compositional
operators on sequences, like concatenation, zipping etc, then the
empty sequence may be useful as a sort of 'null' element. I use Matlab
a lot, which is entirely built around arrays (rather than recursively defined
lists) and the empty array is often useful.
> ~ olo:index - to enable a single index association to a slot in an
> ordered list
> ~ anonymous inverse property of olo:slot to rdfs:type
> owl:FunctionalProperty
>
> With that changes it should be possible
>
> ... to create a unique neighbourhood relation; the list ends if the slot
> hasn't a neighbour (that means no is:next property is set)
I would be wary of defining the end of a list on the basis of the absence
of certain triples - in an open world this leads to non-monotonic
reasoning (see Graham's point below). I think the length the list should
be defined by the length property alone. If the length property cannot
be found, then we don't know what the length of the list is, except that
it must be >= the maximal slot index that we know about. If the length
is N, then even if not all of the slots 1..N can be found, we know they
must exist. Re. Graham's comment, the length *is* the 'maxSlotIndex'.
Samer
Bob Ferris
thanks again for your insightful comments.
Am 28.06.2010 15:56, schrieb Samer Abdallah:
>
> On 28 Jun 2010, at 13:03, Bob Ferris wrote:
>
> Hi Bob, I have a few comments about this below..
>
>
>> thanks a lot for this suggestion. I spent some more time in making this
>> concept a bit more solid [1,2]. Here the features that I added/changed
>> in the v0.3 proposal (+ for added, ~for modified):
>>
>> + olo:next - to associate the next slot of a slot in an ordered list
>
> I'm wondering if this isn't redundant, given that it's derivable:
>
> next(S1,S2) == exists Seq . has_slot(Seq,S1)& has_slot(Seq,S2)
> & index(S1,N1)& index(S2,N2)& succ(N1,N2).
>
> Are you proposing that olo:next be used in the raw representation
> of RDF data, or that it be used as a short cut for writing queries?
Yes, you can see this property as another shortcut for query optimisation ;)
I think, it is more or less quite similar to lists in Java or several
other OO languages. On the one hand, you could access each element
explicitly by its index. On the other hand, you could iterate over the
list, by fetching on element after the other. This might be extremely
helpful if there are very long lists in use.
> I feel that, in choosing a representation based on numerically indexed
> slots (basically, arrays), we've made our bed, as it were, and now have to
> lie in it. And it's an iterative/for-loop style bed. If we wanted to do
> recursive list style processing with 'next', as in LISP, Prolog etc,
> then we should go with a recursive list model, like rdf:List, but with
> without the OWL-related problems. Both approaches have their
> uses so I wouldn't say one is better than the other.
For me the 'mistake' with rdf:list is, that I reference another list in
rdf:next. However, I reference another slot in olo:next - that's what I
want ;)
One the one side, I could query the whole list by requesting all slots
(olo:slot). On the other side, I could walk up and down the list by
olo:next or its anonymous inverse property with the rdf:label "is next
of" (so we need no extra explicit property for 'previous').
I like it, when I could use both ways, because they have both their
advantages in their own. Although, the main property, over which the
ordered list is defined, is olo:index, which keeps the order.
So,
1. olo:index
2. olo:next (which is of course optional)
>
> However, perhaps I misunderstand the RDF 'idiom' - is it common
> practice to define properties that can be logically derived from other
> properties?
No, in general it is a best practice to define less property, which can
express more ;)
However, re. practical reasons, it might be sometimes useful to define
some shortcuts. At least, this is my point of view here. Hence, I have
no problems with them.
>
>
>> ~ olo:length - to enable a single length association to an ordered list
>> ~ olo:length - rdfs:range xsd:positiveInteger (no empty lists!)
>
> I'm not sure about this - while an empty sequence might seem to be pointless,
> for many recursively defined algorithms on recursive list data types, the
> empty list is the natural state on which to terminate the recursion.
I think, then we have also to define something like rdf:nil, so we reach
more or less the same status as rdf:list ;)
> The new sequence model is not a recursive data type,
Yes, but I think, it is a difference, when you could also define an
optional interator over the list, rather than defining the list concept
as an recursive data type (maybe I get something wrong, I don't know ;) ).
> so perhaps this
> is not a valid concern, but if anyone wants to start defining compositional
> operators on sequences, like concatenation, zipping etc, then the
> empty sequence may be useful as a sort of 'null' element. I use Matlab
> a lot, which is entirely built around arrays (rather than recursively defined
> lists) and the empty array is often useful.
Well, I see this all from a 'persistence storing view'. That means
before I write/rewrite my graph into a triple-/quadstore the reasoning
(at least a validity check) should be done. That means, I wouldn't
really write an empty list in my triple-/quadstore.
However, I have no problem, if someone would do this. Hence, I roll back
this change and set the rdfs:range of olo:length to xsd:nonNegativeInteger.
For me, everything that happend before, is a task of the engine, which
processes these graph. The graphs are there often in another format
temporarily stored and would be serialized for the write/update task to
the triple-/quadstore. Of course, reasoning should also taken place
during the processing/usage step of the engine (application).
>
>> ~ olo:index - to enable a single index association to a slot in an
>> ordered list
>> ~ anonymous inverse property of olo:slot to rdfs:type
>> owl:FunctionalProperty
>>
>> With that changes it should be possible
>>
>> ... to create a unique neighbourhood relation; the list ends if the slot
>> hasn't a neighbour (that means no is:next property is set)
>
> I would be wary of defining the end of a list on the basis of the absence
> of certain triples - in an open world this leads to non-monotonic
> reasoning (see Graham's point below). I think the length the list should
> be defined by the length property alone. If the length property cannot
> be found, then we don't know what the length of the list is, except that
> it must be>= the maximal slot index that we know about. If the length
> is N, then even if not all of the slots 1..N can be found, we know they
> must exist. Re. Graham's comment, the length *is* the 'maxSlotIndex'.
Yes, that's also my opition ("the length *is* the 'maxSlotIndex'"). And
again, the olo:next property is an optional one. That means, we know of
course the size of the list by the property olo:length. However, if we
use the iterator for exploring the ordered list, than we also know the
end of this ordered list, if we would access an olo:next property, which
isn't defined in that olo:Slot instance. It's also the other way around,
we know the beginning of this list also, if there isn't an anonymous
property defined, which has as subject this first slot.
> on the basis of the absence of certain triples
That seems a bit strange to me. That sounds more like an processing
error in my mind. If you don't find every slot triple of an ordered
list, than this ordered list is ill-defined (from my point of view).
As far as I understand[1], owl:cardinality says e.g. 0..1. Maybe, we
should add owl:someValuesFrom to olo:length, olo:index to force their
existence ;)
It would be good, if someone could verify this issue. I can't find a
clean description re. this issue somewhere. Currently, I tend to say
that we need both properties to express that a concept must used this
property x-times as defined in owl:cardinality. I applied this in the
v0.3 branch[3].
Last but not least, the also mentioned another collections ontology[4],
which might be also of interest. As far as I reviewed this ontology,
there are some restriction missing.
A final thought, if we mark olo:next also as a 'must property', then we
enforce the sequence structure one more time, because every olo:next
could have only one olo:Slot instance as object.
Cheers,
Bob
[1] http://www.w3.org/TR/2004/REC-owl-guide-20040210/#simpleCardinality
[2] http://www.w3.org/TR/2004/REC-owl-guide-20040210/#owl_someValuesFrom
[3]
http://motools.svn.sourceforge.net/viewvc/motools/orderedlistsonto/branches/orderedlistsonto_v03/rdf/orderedlistontology.n3
[4] http://swan.mindinformatics.org/spec/1.2/collections.html
Bob Ferris
FYI, I recently discovered the Resource List Ontology[1], which seems to
be quite to the Ordered List Ontology[2]. The only difference is more or
less that they used rdf:seq as based.
Other features, e.g. resource:Section or resource:list, I figured also
out in the Play Back Ontology with in the playlist concept[3].
What do you think about this ontology? Should we use it instead of the
ordered list ontology?
Cheers,
Bob
[1] http://vocab.org/resourcelist/schema
[2] http://purl.org/ontology/olo/orderedlistontology.html
[3] http://smiy.sourceforge.net/pbo/gfx/pbo_-_playlist_concept.gif
Samer Abdallah
are simple and general enough to form a good unit of functionality. The
'Sections' business looks a lot like nested lists to but I confess I didn't
look at it that closely.
Go OLO.
S.
> --
> You received this message because you are subscribed to the Google Groups "Music Ontology Specification Group" group.
> To post to this group, send email to music-ontology-sp...@googlegroups.com.
> To unsubscribe from this group, send email to music-ontology-specific...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/music-ontology-specification-group?hl=en.
>
Bob Ferris
Am 28.07.2010 19:48, schrieb Samer Abdallah:
> it looks complicated.
Well, the difference between their and our pattern is, they do more or
less simply refine rdf:Seq and hence, they also have to rdf:_1 ...
rdf:_n for indexing the slots.
We "outsourced" the indexing into the slot itself (olo:index). This
enables a better subclassing of the whole list concept itself
(olo:OrderdList and olo:Slot) for specific use cases and ranges (as
demonstrated with pbo:Playlist and pbo:PlaylistSlot).
> I think our ordered lists (tautology notwithstanding :)
> are simple and general enough to form a good unit of functionality. The
> 'Sections' business looks a lot like nested lists to but I confess I didn't
> look at it that closely.
Yes, it's more or less the same, I did now with pbo:FixedPlaylist (maybe
we need a better name for this concept):
"A (sub) playlist of a fixed length and a fixed order. This concept
should be used to express static relations, e.g. "those three music
tracks must always be played in a row"."
A pbo:FixedPlaylist instance would currently attached as
pbo:playlist_item to a pbo:PlaylistSlot in a pbo:Playlist. However, I
thought also about, whether it would probably better to attach this
nested list directly as pbo:PlaylistSlot. That means:
pbo:FixedPlaylist rdfs:subClassOf pbo:Playlist, pbo:PlaylistItem
That's the way, they did it with resource:Section - it would be directly
attached to the resource:List (as substitution of resource:Item).
> Go OLO.
Yes, go OLO go! ;)
Cheers,
Bob