RE: [OPEN] and/or [PORT] : a practical question

Jeremy

Thanks for the long answer

<snip> Stuff we agree upon </snip>

> Thus if PhDThesis is an owl:Class what are the resources that we intend to
> belong to it? Probably my PhD Thesis with title "Graph Grammars: an
> approach to transfer based MT; exemplified by a Turkish-English system" is
> one such resource, but the copy sitting on my bookshelf is probably not.

This is yet another issue, distinction between a 'generic' document and this particular
one on the shelf, maybe a specifically annotated and dedicated one. And more so with
electronic documents. This is quite easy to tackle if needed : make distinct classes
"Abstract_Document" and "Physical_Document", with a FunctionalProperty "copyOf" linking
the latter to the former. Seems to me that dc properties are asserted for
Abstract_Document only. Physical Documents have other properties, like location, serial
number, owner ...

> Then if that is the case what would we mean by dc:subject linking the
> resource of my thesis with this class .... hmmm ... we mean my thisis
> belongs to that class, i.e. rdf:type.
> So if we want to treat this subject hierachy as classes we really also want
>
> dc:creator rdf:subPropertyOf rdf:type .

?? Suppose you mean dc:subject ??

> or perhaps
>
> eg:creator rdf:subPropertyOf rdf:type .
> eg:creator rdf:subPropertyOf dc:creator .

I'm reluctant with subtyping rdf:type when I can do otherwise (don't mingle with core
vocabulary ...)

> But if we click on dc:creator we get to:
> http://purl.org/dc/elements/1.1/subject

...

> "Typically, a Subject will be expressed as keywords,
> key phrases or classification codes that describe a topic
> of the resource.  Recommended best practice is to select
> a value from a controlled vocabulary or formal
> classification scheme."

> and we see that dc:subject should typically be a string from a controlled
> vocabulary. Thus it seems particularly poor practice to deviate from the
> preferred usage of dc:subject in order to (over-)simplify our model.

Hmm. Does 'value' in dc means necessarily 'string'? If one has a proper subject indicator
identified by an URI, what is wrong with using it, like in :

ex:Jeremy_Thesis  dc:subject  thesex:Graph_Grammars

Where thesex is a thesaurus namespace, used to set subject identifiers.

> This points to the solution I was earlier advocating of using such strings,
> using hasValue restrictions to map the strings into classes and then using
> the class hierachy on those restrictions to show the hierarchical
> relationships between the subject vocab terms.

You refer to your suggestion

<owl:Class rdf:ID="PhDThesis">
   <owl:equivalentClass>
       <owl:Restriction>
          <owl:onProperty rdf:resource="&dc;subject"/>
          <owl:hasValue>PhD Thesis</owl:hasValue>
       </owl:Restriction>
    </owl:equivalentClass>
</owl:Class>

Does that mean what you say above ? Seems to me it means something else, rather silly in
fact, that the subject of a PhD Thesis is PhD Thesis. Hmm. I thought yours was about Graph
Grammars :))

> To do this well, we probably
> want to specialise the dc:subject property with a subproperty eg:subject,
> specify its range with an owl:Datarange explicitly enumerating the
> controlled vocabulary, and for each term create a class using a hasValue
> restriction.
> For further clarity and usablility we might want to create two related
> properties, one indicating the (single) intended subject code, and the
> other indicating all implicit subject codes formed from the class hierachy.
> The former would be a subproperty of both the latter and dc:subject; the
> latter would be used to create the hasValue restrictions.

I've hard time following you at that point. Could you wrap all that in an example in OWL?

> Hmmm ... quite a lot of work initially, but the end result is that the
> subject indicators are marked up using text strings from an explicit
> controlled vocab; we conform with the defn of dc:subject, even with the
> advertised best practice; we fall within OWL DL with the expectation that
> this will give us better reasoning performance, and we have been clearer
> about we are trying to say. I think the complexity can be hidden from the
> end users.

Agreed for most of it, and particularly the last sentence, which is certainly a top list
BP ...
... except that I do not see why the 'object' of the dc:subject predicate could not be a
resource, as long as it is not a class.

I had also an answer from Aldo along the same lines, of which cc to the list was not
forwarded apparently.

Bernard Vatant
Senior Consultant
Knowledge Engineering
Mondeca - www.mondeca.com
bernard.vatant@mondeca.com

Received on Wednesday, 24 March 2004 12:41:24 UTC