Metonyms, # or /, mimetypes, named graphs

This is long and rambling, apologies, ... I am hoping that maybe danbri 
or pat or anyone else might chose to read it all and comment, and then 
maybe in a bit a somewhat more succint version might emerge (or not).

I was sitting on my balcony just after dawn this morning, smoking a 
cigarette and drinking some coffee (instant, apologies; I had a 
cappuccino at the bar later).

I was thinking about xsd:int, the URI

http://www.w3.org/2001/XMLSchema#int

When you use this URI with type rdfs:Datatype, then you mean a datatype, 
(the one defined by XML Schema).

We can say

[A]

xsd:int rdf:type rdfs:Datatype .

On the other hand, if you read this URI according to same XML spec, (I 
am not sure which one), apparantly the frag ID identifies an element in 
the XML document

http://www.w3.org/2001/XMLSchema

at a guess that is this XML document

http://www.w3.org/2001/XMLSchema.xsd

and hence this element


   <xs:simpleType name="int" id="int">
     <xs:annotation>
       <xs:documentation
         source="http://www.w3.org/TR/xmlschema-2/#int"/>
     </xs:annotation>
     <xs:restriction base="xs:long">
       <xs:minInclusive value="-2147483648" id="int.minInclusive"/>
       <xs:maxInclusive value="2147483647" id="int.maxInclusive"/>
     </xs:restriction>
   </xs:simpleType>

Thus, from a different point of view, we could say

[B]

xsd:int owl:sameAs """<xs:simpleType name="int" id="int">
     <xs:annotation>
       <xs:documentation
         source="http://www.w3.org/TR/xmlschema-2/#int"/>
     </xs:annotation>
     <xs:restriction base="xs:long">
       <xs:minInclusive value="-2147483648" id="int.minInclusive"/>
       <xs:maxInclusive value="2147483647" id="int.maxInclusive"/>
     </xs:restriction>
   </xs:simpleType>"""^^rdf:XMLLiteral .

(modulo XML canonicalization)

Both [A] and [B] are legitimate (I think), but put them together to form 
a single graph [A U B] and we get nonsense (a contradiction).

Basically [A] and [B] take different views of the world, and are 
appropriate for different tasks.

This is reminiscint of:
- named graphs
See
http://www.hpl.hp.com/techreports/2004/HPL-2004-57.html

- metonymity
    Putting the sentences:
     "Smith summed up for the crown"
with
     "The crown weighs 4 kilos"
   gives nonsense, since the former sentence takes a view of "the crown" 
as standing for something other than a crown (the power of the state in 
a monarchy)

- the problem of whether an http URL (without a frag ID) can ever stand 
for something other than a document.


====

We already have a mechanism for taking different views of a resource: 
mime types.

====

We could, as always, resolve this by adding another level of 
indirection; using more sophisticated modelling. e.g. maybe instead of

xsd:int rdf:type rdfs:Datatype .

we should have said

_:d rdf:type rdfs:Datatype .
_:d rdfs:isDefinedBy xsd:int .

However, since we can always say that, but in practice we have to decide 
how many levels of indirection to have, and usually it is easier to have 
none. I think the "your modelling is poor" argument, at the end of the 
day, is uncompelling. It is unfalsifiable, any modelling is always poor, 
because by it's very nature it approximates the way the world is (as if 
we knew) rather than giving a perfect reflection (oh, the joy of 
omniscience).

That's not to say that one model is as good as the next, but ...

====

If we were going to take the modelling argument seriously (which I am 
not), we might then put this together with mimetypes. Since we don't 
have URIs for mimetypes, we will coin a functional property 
eg:hasMimeType, and jumping in, I reveal my ignorance of mimetypes, we 
might have:

_:d rdf:type rdfs:Datatype .
_:d eg:hasMimeType "x-semantics/rdf-datatype" .
_:d eg:isRepresentationOf xsd:int .


and

_:x rdf:type eg:XMLElement .
_:x eg:hasMimeType "application/xml-frag" .
_:x eg:isRepresentationOf xsd:int .
_:x owl:sameAs """..."""^^rdf:XMLLiteral .

Now, these two graphs can be merged without contradiction.

====

So, since I am underwhelmed by the modelling argument, I consider 
metonymity.

In [A] we are taking one view of xsd:int, that represented by the 
(hypothetical) mimetype "x-semantics/rdf-datatype"; in [B] our view is 
with the (hypothetical?) mimetype "application/xml-frag".

Perhaps we should just add this information to the class definitions.

e.g.

rdfs:Datatype eg:hasMimeTypes [
    "x-semantics/rdf-datatype"
] .
eg:XMLFragment eg:hasMimeTypes [
   "application/xml-frag"
   "application/xml"
   "application/xhtml"
] .

(Perhaps the list of possible mimetypes should be open rather than closed)

If we then merge two graphs, the view of any specific resource taken in 
the merge must be using a mimetype occuring in each of eg:hasMimeTypes 
list for every class that that resource is in. Thus, if as in this case, 
the lists have an empty intersection, we know that the views taken are 
contradictory, and we appropriately choose not to merge them. (Using the 
named graphs approach)

===

A different example might be a URI of an image e.g.

http://www.hpl.hp.com/personal/jjc/images/venn.png

We might want to discuss this image as a bitmap, talk about its height 
and width in pixels (this discussion would be meaningless for an SVG 
version of the image)
We might want to discuss this image as an abstract image, talk about the 
colours used, mention that is a geometric design ... (this discussion 
would be meaningless for say a text document giving the 18 coordinates 
which define the image)
I, at least, might want to discuss the deeper significance of the image 
as a piece of abstract mathematics: I would see such a discussion as 
typically appropriate to many variations of this image, including ones, 
where the image was abstracted to being simply a planar graph, with no 
indication of the (Euclidean) geometrical representation.

These three different discussions, are, in my view, all legitimate 
discussions about the image. They seem to be discussing different facets 
of the image. They are incompatible discussions. We have to switch 
world-views to go from one to the other.

Could (an extension of) mimetypes be used to distinguish these different 
discussions, like with the xsd:int example?
I think so.

====

# or / ?

I think the dogmatic # position in this debate is predicated on http 
URLs denoting documents, and not more abstract concepts. If we can see 
the more abstract concepts as merely another metonymic representation of 
the (abstract) document, with an appropriate mimetype, then maybe the 
problem goes away.
I haven't yet understood the dogmatic / position, only the pragmatic one.

====

I smoked another cigarette and started my day.

Jeremy

Received on Friday, 11 June 2004 08:23:56 UTC