Re: Upcoming telecons

The diagram is great because it gives us something to react to.

A note first about method: What I would like to see done is to put
down many different class terms from many different ontologies and
vocabularies and specs, as we have started to do, and then get to the
point where we can answer the question, for any two classes A and B,
how they relate.  That is:
  - A {disjoint, subclass, superclass, equivalent to} B, or
  - some other property (relation) connects them, such as "comes from"
or "is part of", or
  - relation can be inferred by composing other relations, or
  - definitions are not specific enough to determine relation (but may
partiallly determine it, e.g classes could be equivalent OR one could
be a subset of the other)
Any definite conclusion should have justification, as in: specified
either by external document or by the group; or group consensus is
that it's obvious; and for any difference between classes, it has to
be possible to come up with something that is in one class but not in
another.

One could simply write out all n^2 relations, or a representative
subset, but there is probably a more economical way.

Ideally distinctions between classes should be manifest in properties.
That is, if A is a subclass of B, then there has to be some statement
x P y, with suitable axioms for x, P, and y, that is true if x is
assumed to be in A and false if x is assumed to not be in A (or v.v.).
I don't know how to make this rigorous yet, but I believe the idea has
been articulated by others (Barry Smith maybe?).

If this can't be done, simply define a URI for some individual x, give
it adequate documentation to justify its existence, and assert that
it's in B but not A.

I think we will get to points where there's not enough information to
decide and the group does not have consensus.  Then we will just have
to document this and live with a theory that admits multiple models in
which different conclusions hold. In fact it is understanding the
range of admissible models that may be the most interesting part of
this exercise.

An example of incompleteness is the relation between
fftr:InformationResource and awww:InformationResource. To me these may
intersect (there are some functions whose essential characteristics
may etc.) but neither contains the other (there exists at least one
FFTR whose ECs cannot be etc. / there exists at least one thing whose
ECs etc. that is not a function). However, others in the group are
likely to have other opinions, and we may just be unable to agree.

That is - there will be many ?'s that simply cannot be eliminated. It
would be good to record everyone's positions somewhere, though, if
there is disagreement. Any arc without a ? has to have its
justification recorded or accounted for somehow.

And if there is no operational import to some of these questions, they
just don't matter - except that each incompleteness has the potential
to lead to annoying and pointless disagreements (such as Tim
surprising me by saying that the essential characteristics of 3 can't
be communicated in a message!).

Specific comments:
- awww:isNamedBy should be changed to awww:isIdentifiedBy  (as I now
understand that these are not the same). Documentation should make it
clear that this is a highly subjective, underspecified relation that
may be modeled in wildly different ways in different models. Anyone
talking about it ought to focus on theory and entailment (proof), not
truth.
- you must remove NonInformationResource from the discussion as both
Tim and I will scream bloody murder if it's there.  This should not be
a top-level split in the ontology; if you need an upper ontology with
natural upper-level divisions we should choose one... but I don't
think we do.
- consider adding Information Artifact Ontology to the mix (google it)
- an rfc2616:Entity is part of a http:Message.  I think BFO might have
a suitable part_of relation.
- please do not use the namespace prefix 'http:' as it is leads to
confusion. Tim has use 'htp:' which is not beautiful; perhaps you can
come up with another.
- it's not obvious that a FixedResource is a kind of rfc2616:Resource.
 I don't think the definition allow you
to rule out that e.g. a data: resource might be a FixedResource but
not a rfc2616:Resource.
- speaking of which the vocabulary needs to exclude data: resources
from web resource, as data: resources are not obviously on the web.
(you can visit the in your browser, so maybe they are "browsable
resources". I don't know)
- the relationships between the various kinds of representations and
entities need to be spelled out. Clearly an rfc2616:Entity is very
similar to an awww:Representation; in what situation
- I have argued against rfc2616:Representation, as the class coincides
with rfc2616:Entity - to the extent that Roy Fielding is arguing for
elimination of entity in favor of representation in HTTPbis!  That is,
every entity is the representation of *some* resource - just not
necessarily the one you requested. I guess we could argue whether this
is justifiable but the distinction just isn't operational in any way
so I don't see the point of having both.
- at some point we need to go back and look at the RDF work David
Booth and Stuart Williams did at the beginning of the project, and
recast it in the ontology. Hypotheses about relations to other things
we've looked at, such as FRBR and Valentina's and Aldo's work, would
be nice.

I would like to see the REST, CN, and "abstract document" or
GenericResource (TimBL) aspects fleshed out. (By REST I'm referring to
the 2000 ICSE paper, which has to be taken with a lot of salt since
it's meant as a software architecture, not an ontology.) For example,
we might say that all REST-conformant resource are TimBL generic
resources, but that there are rfc2616 resources (maybe some of its
fabled "network services") that are *not* REST-conformant.

Ultimately we may need a rational reconstruction along IAO lines, but
I want to take this approach to the end first. With someone actually
paying attention the end may be nearer than we think.

I am really overloaded now so if I don't respond carefully or in a
timely manner don't take that as intentional neglect.

Best
Jonathan

On Sun, Feb 22, 2009 at 4:06 PM, Michael Hausenblas
<michael.hausenblas@deri.org> wrote:
> Jonathan, All,
>
> Sure, 10 March sounds fine for me.
>
> To get deeper into the current discussions, I went through the vocabulary
> page [1] and (tried) to create the dependencies and relations of the
> proposed classes and properties - the result is available at [2].
>
> I note two things: some of the graph's edges are undefined (?) as it is not
> clear from the discussion on the Wiki page what to put there. Further, by
> strictly applying the (natural language) constraints found in [1], I guess
> we have a slight inconsistency between awww:InformationResource,
> ftrr:InformationResource and rfc2616:Resource.
>
> I'd propose three next steps: (1) get rid of the '?' in the diagram, (2)
> define the grounding w.r.t. HTTP-in-RDF, and (3) discuss the open issues
> around :NonInformationResource and :DescriptionResource.
>
> What do you think?
>
> Cheers,
>      Michael
>
> [1] http://esw.w3.org/topic/AwwswVocabulary
> [2] http://esw.w3.org/topic/AwwswVocabularyDependencies
>
> --
> Dr. Michael Hausenblas
> DERI - Digital Enterprise Research Institute
> National University of Ireland, Lower Dangan,
> Galway, Ireland, Europe
> Tel. +353 91 495730
> http://sw-app.org/about.html
> http://webofdata.wordpress.com/
>
>
>> From: Jonathan Rees <jar@creativecommons.org>
>> Date: Sun, 22 Feb 2009 14:04:41 -0500
>> To: "public-awwsw@w3.org" <public-awwsw@w3.org>
>> Subject: Upcoming telecons
>> Resent-From: "public-awwsw@w3.org" <public-awwsw@w3.org>
>> Resent-Date: Sun, 22 Feb 2009 19:05:24 +0000
>>
>> Our next regularly scheduled times are 3/3, 3/17, and 3/31.
>> Unfortunately I am unavailable the first two of these (3/3 = TAG in
>> California, 3/17 I will be in Europe). Well, I might be able to make
>> 3/3 since I will be jetlagged and wide awake at 6am, but it's a stretch.
>>
>> I suggest we talk on 3/10 at 9am and then on 3/31, and get as much as
>> possible done in email in the meantime. Thoughts?
>>
>> Jonathan

Received on Monday, 23 February 2009 14:58:54 UTC