Структура данных Haskell для СКОС (семантическая сеть)

Введение

Я программирую семантическое веб-приложение в haskell.

С hsparql http://hackage.haskell.org/package/hsparql я могу получить доступ к моему Tripple Store . В настоящее время я использую http://4store.org/ (главным образом потому, что его было легко установить). Я использую snap http://snapframework.com/ для программирования сервлета (Yesod тоже очень классный!!).

В настоящее время я использую SKOS для представления категорий закладок в RDF.

Ссылки на СКОС:

По сути, Skos Concept — это категория. У него есть URL-адрес (как своего рода идентификатор) и метка. Дальнейшие концепции Skos могут иметь подконцепции, определяемые как «шире» и «уже».

Например, в моих закладках есть концепция SKOS «все закладки» с подконцепцией «закладки haskell». И обе концепции имеют URL-адрес (например, как идентификатор) и метку. Также «закладки haskell» имеют отношение к более широкому понятию «все закладки».

Моя проблема

Мне нужна структура данных в haskell для SKOS.

Мой текущий:

-- Type Aliases.

type Url = String
type Label = String


-- Date Structure.

data SkosConcept = SkosConcept {
      url :: Url
    , label :: Label
    , subConcepts :: [SkosConcept]
    } deriving (Show)

Я думаю, что это не очень хороший способ, но я не знаю лучшего.

Кроме того, в будущем структуру данных необходимо расширить до нескольких меток и средств для хранения связанных концепций,...

Также некоторые понятия могут не иметь подпонятий.

Любые указатели на то, как улучшить структуру данных или «сделать это правильно»?

===== РЕДАКТИРОВАТЬ: ======

Проблема в том, что концепция skos может иметь несколько более широких концепций skos. Таким образом, мои «закладки haskell» могут иметь две более широкие концепции skos (например, категории), называемые «закладки программирования» и «мои важные закладки».

Единственные решения, о которых я могу думать на данный момент, используют:

  • ориентированный граф для «более широкой» связи понятий skos
  • бинарное отношение «шире» (но я не знаю, есть ли хорошая поддержка haskell)
  • никаких промежуточных структур данных, и все мои функции запрашивают RDF Tripple Store

haskell semantic-web
person mrsteve    schedule 07.11.2011    source источник
comment
Я думаю, что вы задаете здесь концептуальный вопрос, и речь идет только о синтаксисе, так что это не совсем ответ, но... addSubConcepts можно значительно улучшить с помощью синтаксиса записи: addSubConcepts concept subList = concept { subConcepts = subList }. В зависимости от того, как вы ее используете, возможно, даже не стоит записывать эту функцию.   -  person Daniel Wagner    schedule 07.11.2011
comment
спасибо за улучшение синтаксиса.   -  person mrsteve    schedule 07.11.2011
comment
Почему вы думаете, что ваша структура данных не очень хороша?   -  person jmg    schedule 07.11.2011
comment
У меня есть ощущение, что текущая структура данных недостаточно расширяема, если я добавлю больше возможностей SKOS. Также в настоящее время концепт без субконцепта хранится в виде пустого списка. Я думаю, что использование ', subConcepts :: Maybe [SkosConcept]' было бы лучше. Я все еще новичок в haskell, и время от времени у меня возникают проблемы с некоторыми базовыми вещами, такими как синтаксис записи.   -  person mrsteve    schedule 07.11.2011

Ответы (1)


arrow_upward
1
arrow_downward

Вместо того, чтобы пытаться сохранить двунаправленную структуру напрямую, почему бы не использовать стандартный подход Graph и не сохранить кортеж, содержащий как набор понятий, так и набор отношений между понятиями?

cf: http://hackage.haskell.org/package/fgl

person sclv    schedule 22.11.2011