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