Re: New Draft comments: textual bodies

Hi Bob,

You are right.

I personally don't mind much when an ontology becomes OWL Full: I can live with every property just typed as rdf:Property. And coming from a community where it is difficult to enforce strict constraints on the data at once, I much appreciate the flexibility of DCMI properties!
But I understand if some prefer to keep compatibility with OWL DL or some other contrained OWL Profile (have we got a requirement like that anywhere?).

Anyway, this gives more motivation for detailing some of the SKOS stuff I refrained from explaining in my previous mail.

Documentation properties:
http://www.w3.org/TR/skos-reference/#notes
These properties (skos:note, skos:definition, etc) can be used with both literals and resources. This raises indeed some problem with OWL-DL. They were solved by declaring the documentation properties as OWL annotation properties, which are OWL-DL compatible. But this prevents from using them in some formal axioms (don't ask me which ones now!).
This may mitigate your fear in solution #2. But it would require more investigation on (1) which axiom we want for oa:hasBody, (2) which axioms could others create, that use hasBody (e.g., if someone wants to create a sub-class of Annotation that has a constrained number of bodies), and whether it is really harmful to have these extensions fall into OWL Full.


SKOS-XL labels as resources:
http://www.w3.org/TR/skos-reference/#xl
SKOS-XL introduces labeling object properties (skosxl:prefLabel, skosxl:altLabel, skosxl:hiddenLabel) that mirror the 'basic' SKOS datatype ones (skos:prefLabel etc). The resources that are object of SKOS-XL proeprties are typed with skosxl:Label and their literal value is given by a datatype property (skosxl:literalForm)
This looks like your solution #1 and I believe #3, the current OA pattern with "Content in RDF" resources attached to hasBody as an object property.
But there is some compatibility between the two ways of representing labels, thanks to property chain axioms (S55, S56, S57) which guarantee that every data in the SKOS-XL patterns also lead (after inference) to data according to the basic pattern. Maybe we could re-use a similar trick to mitigate the downsides of solution #1.

Antoine



> I agree that both are needed.  I don't agree there is no problem.
>
> If I am not mistaken, OWL DL, at least, requires that data properties
> not be object properties, and if oa:hasBody is declared as both, then
> it is turned into two predicates with the same name.  Surely this
> problem is not restricted to hasBody and all such properties would
> seem to have only these three solutions:
> 1. implicitly or explicitly duplicate such properties.
> 2. Take the possibility of an OWL DL representation of OA off the
> table (or any other ontology with such a restriction )
> 3. Adopt some solution like Content in RDF, wherein hasBody remains an
> object property, and literals are hung off an object of standardized
> type.
>
> FWIW, some of dcmi-terms is a mess because of not treating this
> problem rigorously.
>
> Bob Morris
>
>
> On Sun, Jan 6, 2013 at 3:21 PM, Jacco van Ossenbruggen
> <Jacco.van.Ossenbruggen@cwi.nl>  wrote:
>>
>> On Jan 6, 2013, at 4:51 PM, Antoine Isaac<aisaac@few.vu.nl>  wrote:
>>
>>> "This model was chosen over having a literal as the Body directly for the following reasons:"
>>> I'm sorry, but I still don't buy most of the reasons. And I believe I won't be the only one…
>>
>> I fully agree with Antoine here.
>>
>> I think all arguments given in the document are very good arguments to argue for _allowing_ bodies to be URI resources for those who need them to be. I'm all for that. But I do not buy any of the arguments as a solid argument _disallowing_ literal texts as bodies for those who prefer them to be literals.
>>
>> I can see problems when you do not allow URI bodies.
>> I can see problems when you do not allow literal bodies.
>> But I cannot see what problems arise when you allow both.
>>
>> Jacco
>>
>> PS:  "Representing Content in RDF 1.0" seems like a spec that is dead on arrival… is there any evidence it is not?
>>
>>
>
>
>

Received on Sunday, 6 January 2013 21:30:57 UTC