[Fwd: Subclassing lists in W3 HTTP Vocabulary]

FYI. I think the resources [1] and [2] should (eventually) be updated.

-------- Original-Nachricht --------
Betreff: Subclassing lists in W3 HTTP Vocabulary
Datum: Fri, 14 May 2010 17:03:30 +0100
Von: Hogan, Aidan <aidan.hogan@deri.org>
An: <johannes.koch@fit.fraunhofer.de>,	<carlos.velasco@fit.fraunhofer.de>
CC: <pedantic-web@googlegroups.com>

Hi folks,

Hopefully I'm contacting the right people; if not could you forward as
appropriate?

I was looking to use the vocabularies at [1,2] to model HTTP headers
found during an RDF crawl. However, there are some errors in the
modelling.

In [1], you declare the classes #Connection, #MessageHeader,
#HeaderElement and #Param to be subclasses of lists. Also, in [1], I'm
pretty sure you can't pack min and max-cardinality definitions into the
same owl:Restriction. Also, #RequestURI is defined as either an
"asterisk" or the *term* rdfs:Literal.

With respect to general feedback, I would throw away a lot of the more
expressive constructs and provide a HTML description at the namespaces:

* Remove cardinality-encoding restrictions, which do not provide any
useful Inferencing and generally complicate the vocabulary -- I would
instead specify the constraints in a natural language description. (In
any case, you will not be able to model all "constraints" in OWL and the
interpretation of cardinalities in OWL are not constraints).
* #responseCode can have a xsd:positiveInteger or a #ResponseCode
resource: I would remove the option (and the owl:unionOf construct) and
choose one range or the other to ensure uniformity in exports. The same
goes for #fieldName (I would lean towards supporting the latter and
adding the response-code integer to the labels of the respective
resources -- e.g., "200: OK" as opposed to "OK".)
* The use of owl:oneOf in both [1] and [2] do not provide anything
useful, and only serve to restrict future extension of the vocabulary
(e.g., extending [2] with new standard #HeaderName members would change
the semantics of the #HeaderName class). Instead just explicitly type
the header names as #HeaderName members.

Generally, I would lean towards a much more lightweight modelling
(something like using the terms defined in [2] as properties).

Cheers,
Aidan

- http://pedantic-web.org

[1] http://www.w3.org/2006/http
[2] http://www.w3.org/2006/http-header
[3] http://www.w3.org/TR/HTTP-in-RDF10/


-- 
Johannes Koch
Fraunhofer Institute for Applied Information Technology FIT
Web Compliance Center
Schloss Birlinghoven, D-53757 Sankt Augustin, Germany
Phone: +49-2241-142628    Fax: +49-2241-142065

Received on Friday, 14 May 2010 18:03:15 UTC