Support for skos:orderedCollection and rdf:List in EVN

조회수 73회
읽지 않은 첫 메시지로 건너뛰기

Carl Burnett

읽지 않음,
2017. 5. 25. 오후 12:17:2017. 5. 25.
받는사람 topbrai...@googlegroups.com

In certain situations, I would like our EVN users to be able to curate ordered lists of concepts or other resources (most likely, content assets). For example, a common scenario for us is to say that an article maps to several videos, which ought to be presented (in some downstream UI) in a fixed order. One way to do this would be to create a resource representing the list of videos and then simply assign an index to each video, like this:

 

:Article 1 :maps_to :VideoList .

:VideoList :contains :Video1, :Video2, :Video3 .

:Video1 :index 1 .

:Video2 :index 2 .

:Video3 :index 3 .

 

A problem with this approach is that we will want to create other video lists in which the same videos appear in a different order.

 

When working in a SKOS vocabulary, Concept Collections would appear to be a good solution to this problem. In TBC, it is no problem to model the above scenario according to the SKOS standard:

 

:VideoList

  rdf:type skos:OrderedCollection ;

  skos:memberList (

    :Video1

    :Video2

    :Video3

  ) .

 

Unfortunately, EVN Taxonomies seem to be unable to represent SKOS collections at all; when I create one with this data, my resource :VideoList is nowhere to be found – which makes sense, since EVN Taxonomies display only Concepts and Concept Schemes, and skos:Collections, by definition, are neither.

 

The situation is slightly better if I create the project as an EVN Ontology: I can see that :VideoList is an instance of the class skos:OrderedCollection and that it has a member list. Unfortunately, EVN does not seem to be able to represent the SKOS member list as representing a set of known concept resources (screenshot), even though all of its members are properly typed and labeled (screenshot).

 

I noticed that the domain of the property skos:memberList is declared to be rdf:List, and it is true that the list I added in Composer is not declared to be of that type. (Composer does not seem to mind having an untyped list fill that slot.) So the next thing I tried was to replace that list with a properly formatted rdf:List:

 

:VideoList

  rdf:type skos:OrderedCollection ;

  skos:memberList :AwesomeVideoList ;

  rdfs:label “Video list” .

:AwesomeVideoList

  rdf:type rdf:List ;

  rdf:first :Video1 ;

  rdf:rest [

      rdf:first :Video2 ;

      rdf:rest [

          rdf:first :Video3 ;

        ] ;

    ] ;

  rdfs:label "Awesome video list" .

 

Upon importing this data into an EVN project, I realized that I had just pushed the problem down a level: my :VideoList ordered collection looks fine (screenshot), but when I drill into :AwesomeVideoList, it has again failed to resolve the Turtle list syntax that describes the object of rdf:rest into an actual list of typed and labeled resources (screenshot). It seems like the only way to get this work would be to create a nested set of rdf:list resources, one for every item I want to include in my list! (The last one would have no value for rdf:rest.)

 

Surely I’m not the first person to run across this problem. But EVN’s docs say nothing at all about order. And searching the archives of this discussion group, I only see questions about modeling order in TBC (ex1, ex2), not for EVN-managed data projects. Irene and Holger’s answers to ex2 are not exactly encouraging! (I think I am starting to understand Manu Sporny’s disdain for RDF’s treatment of lists.)

 

So. Does anyone have any suggestions for how I might model ordered lists of resources in EVN? Simply replace the recursive “first/rest” model that’s native to RDF with a more basic set of “previous/next” properties? Or should I just resign myself to the caveman approach of creating numbered sub-properties of the property whose values I want to order (e.g., :contains_video_1, :contains_video_2, contains_video_3 … )?

 

 

___

 

Carl Burnett

Ontology Engineer  |  Healthwise

cbur...@healthwise.org  |  www.healthwise.org

(208) 489-8485

 

Healthwise helps people make better health decisions.

 

Holger Knublauch

읽지 않음,
2017. 5. 26. 오후 11:15:3117. 5. 26.
받는사람 topbrai...@googlegroups.com
Hi Carl,

I am afraid the only real solutions here would be to either

1) Create a relationship class that bundles the object with an index, e.g.

:Article1 :maps_to :VideoItem1 .
:Article1 :maps_to :VideoItem2 .
:Article1 :maps_to :VideoItem3 .

:VideoItem1 a :VideoItem .
:VideoItem1 :video :Video1 .
:VideoItem1 sh:order 1 ;

:VideoItem2 a :VideoItem .
:VideoItem2 :video :Video2 .
:VideoItem2 sh:order 2 ;

:VideoItem3 a :VideoItem .
:VideoItem3 :video :Video3 .
:VideoItem3 sh:order 3 ;

2) Use rdf:Lists and add a widget that can handle them correctly. I admit this is really a gap in the current UI support of EVN. We should have better support for properties that have rdf:List as their value type. It should arrange items in rows, but also have buttons to move items up or down. I have recorded this as a requirement for a future release. It's not a trivial amount of work but clearly needed if we want to claim full RDF support.

Does this make sense?

FWIW if you want certain classes to appear in the Taxonomy editor, try making them a subclass of skos:Concept (even if that's just a hack and a temp triple).

Holger
--
You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include the TopBraid Suite family of products and its base technologies such as SPARQLMotion, SPARQL Web Pages and SPIN.
To post to this group, send email to topbrai...@googlegroups.com
---
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

cbur...@healthwise.org

읽지 않음,
2017. 5. 30. 오후 3:30:1817. 5. 30.
받는사람 TopBraid Suite Users
Thanks Holger, this is a reasonable solution. And thanks also for adding the documentation for future support of rdf:list.

C
전체답장
작성자에게 답글
전달
새 메시지 0개