XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] markup humility

Dan, hello.

On 22 Feb 2022, at 12:56, Dan Brickley wrote:

> Once upon a time, we had FOAF include some bits and pieces of DAML+OIL, and
>  then OWL, to show some support and try it out. We stated that foaf:Person
>  and foaf:Document were disjoint types, since the idea of something being
>  both didn't make much sense. And then some time later, we removed that
>  disjointness claim on the basis that the selfsame-thing might be sensible
>  describable as a Person in some ways, but if they had e.g. interesting
>  tattoo art, then that same entity could also be described as a Document (or
>  Image).

That sort of thing could of course be resolved by yet more cunning OWL technology, and higher-level ontologies, and all that, and the resulting debate on how to write it all down would have made the whole httprange-14 thing look like a mild dispute over cucumber sandwiches.

>  It's a pendantic point, but raises maybe a more interesting question about
>  minimalism and simplicity.

>  Was the most pragmatic, simple approach
>
>  (a) to say Person and Document are disjoint, because the tattoo
>  cornercase is a nitpicking clever trick and there are plenty of other
>  constructions you could adopt (e.g. a new relationship) to connect a
>  representation of a person to a representation of their tattoo art.

>  (b) to say nothing about disjointness, because nobody asked us to, the
>  world is complicated, and encouraging developers to think that classes are
>  tidy, crisp-edged things is to mislead them.
>
>  I lean towards (b) which is why foaf:Person and foaf:Document are currently
>  not marked as disjoint types. We don't say they're not disjoint either. One
>  reason that I'm increasingly happy with this approach is that newer
>  validation-oriented standards for RDF have come along, SHACL, ShEx etc., so
>  the core vocabulary definitions don't need to carry the burden of being the
>  only configuration for validators (thankfully!).

Absolutely (b).

If I, for whatever purposes I have in mind, wish to assert that they are disjoint, then it is merely a matter of typing for me to add that assertion to my dataset; if I have different purposes -- perhaps I'm a gallery curator, and have an interest in cataloguing body art -- then I will not; if I have an application where I don't have to worry about reasoning, then I won't bother to add anything.  The mental assumption that foaf:Person and foaf:Document are disjoint may well be useful in the design of FOAF, but you're absolutely right to see a boundary there and refrain from crossing it.

My other favourite example is that http://dbpedia.org/resource/Jordan_River is the River Jordan, whereas http://sws.geonames.org/7874114/ is the River Jordan (that part of it which is in Jordan).  Whether those are equivalent things or not is a question which requires lots of context (cultural and political, on top of the geographical and hydrographical), and which very much depends on a client application.

The open-worldness of RDF (and at this point I'm obviously not addressing just you, Dan) means that such extra sets of assertions can be disaggregated, and swapped in and out as convenient.  But _at least_ if we're both talking about  http://dbpedia.org/resource/Jordan_River  we both know we're talking about the same thing, and as a bonus, if I'm sensitive to the right namespaces, I can probably work out that it's not a book.

Best wishes,

Norman


-- 
Norman Gray  :  https://nxg.me.uk
SUPA School of Physics and Astronomy, University of Glasgow, UK


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS