Re: Metonyms, # or /, mimetypes, named graphs

At 13:22 11/06/04 +0100, Jeremy Carroll wrote:
>Could (an extension of) mimetypes be used to distinguish these different 
>discussions, like with the xsd:int example?
>I think so.

I think MIME types would be the wrong tool for this.  As it happens, I've 
already been forming a view that MIME types are already over-extended by a 
diversity of uses.  MIME started life as an evolution of email formats, 
used to address issues like different character sets and encodings, binary 
attachments, etc.  The MIME content-type (aka MIME type) was a way of 
dispatching physical message content to an appropriate processor.

Some of the limitations of this approach surfaced in the IETF discussion of 
the +xml convention for XML-based MIME types (e.g. as in 
application/rdf+xml).  XML was accepted as being sufficiently common as to 
reasonably constitute a special case, but also recognizing that more 
general extensions of MIME in this direction were likely to be 
unproductive.  Ultimately, a richer form of content description would be 
needed (RFC 2533 and RFC 2912 were mentioned in the course of this 
discussion, by other than myself; e.g. 
http://www.imc.org/ietf-xml-mime/mail-archive/msg00758.html ).

So, I feel that with the role of MIME content-type already stretched to 
fully describe purely physical (as in data format syntactical) aspects of 
data objects, further extending them to deal with abstract semantic 
concepts will be, at best, a cause for confusion.

So, I find myself asking the question:  what do I feel about your proposal 
if I substitute some other attribute for "MIME-type"?  Of that, I'm not 
sure, but as I read I felt that a new "switching point" was being 
introduced into the resource identification framework, whose cost might 
turn out to be somewhat greater than the cost of the problem being 
solved.  Currently, we have URIs (URIrefs) to identify resources, and the 
URI scheme is the single top-level "switching point",  depending on a 
registry that is common to all URIs.  The costs of adding to top-level 
"switchinbg points" has been well documented ("Dividing the Web into 
information destined for different devices, or different classes of user, 
or different classes of information, breaks the Web in a fundamental way." 
-- http://www.w3.org/DesignIssues/TLD , also: 
http://lists.w3.org/Archives/Public/uri/2001Sep/0016.html, 
http://infomesh.net/2001/09/urischemes/ -- I thought there was a more 
extensive piece by TimBL on the problems of URI scheme proliferation, but 
cannot find it.)

Would it really be sensible to introduce another "switching point", which 
might have the effect of creating an overlay on URI space?  What is an 
appropriate interpretation if there is no knowledge of the additional 
attribute?

#g
--

At 13:22 11/06/04 +0100, Jeremy Carroll wrote:


>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
>
>
>
>
>
>
>
>
>
>

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Received on Friday, 11 June 2004 10:29:06 UTC