W3C home > Mailing lists > Public > public-esw-thes@w3.org > February 2005

SKOS Core review Re: issue: non-Literal "comment" properties Re: new draft of SKOS Core guide

From: Dan Brickley <danbri@w3.org>
Date: Fri, 18 Feb 2005 13:33:11 -0500
To: "Miles, AJ (Alistair)" <A.J.Miles@rl.ac.uk>
Cc: public-esw-thes@w3.org, public-swbp-wg@w3.org, swick@w3.org
Message-ID: <20050218183311.GZ11010@homer.w3.org>

+cc: WG list, Ralph (re process/versioning issues below)

* Miles, AJ (Alistair) <A.J.Miles@rl.ac.uk> [2005-02-18 15:48-0000]
> Hi Dan,
> > Re-ping. I don't see a response to this in the archives.
> > http://lists.w3.org/Archives/Public/public-swbp-wg/2005Feb/0057.html
> > 
> > I believe the Guide and the Core spec are in tension. And 
> > that this could be resolved (at this stage in the design anyway)
> > by dropping the 'superproperty: rdfs:comment' claim from the Core.
> > If we are happy with that change happening, the Guide is, I believe,
> > unaffected. The pre-WD core doc could be changed in place, I guess.
> I'm happy to drop rdfs:comment as a super-prop for all 'documentation properties' 
> - I think this has to be done for the reasons you describe.

OK. Let's do that. Though note that this'll cost us in the case of those scenarios
which do shadow rdfs:comment usage, ie. search/browse tools based on
label/comment won't see SKOS labels. Maybe that's OK since generic RDF
vocab browsers will be structured in terms of classes and properties
anyway, rather than networks of concept-descriptions. So some rejigging
is going to have to happen regardless of property name for the text
> > Thoughts? I'm a little concerned w/ referencing the non-WD core spec
> > from a WD. How much more work do you reckon there is on the main doc,
> > Alistair?
> I was thinking that the SKOS Core Spec [1] is pretty much ready to go, 
> waiting on comments from Tom & Mark & yourself esp. re the 'policies' 
> section I added last week.  Aiming to propose the SKOS Core Spec for 
> first WD at the SWBP-WG telecon next thursday (24th feb), which depends on 
> approval by Tom and Mark by tuesday/wednesday if they are willing to give it.

If it is ready to go, should we hold off on the Guide and have the two
go out together, cross-referenced? Or can we just put a redirect in? I
think a "first working draft" is an attention-capturing event, people
will print it out, think about it, etc. Do we want them to consider both
docs at same time?

OK, reviewing http://www.w3.org/2004/02/skos/core/spec/

number points for appearance of structure...

1) navtool positioning
CSS tweak? Right hand navtool, I see the longer words being cut off from
right hand side, ie. "CollectableProper", "isPrimarySubjectO", could you 
nudge that leftwards a little, perhaps. Since in Firefox at least, I
can't resize that box, but I can widen the window if the navtool
encroaches on the main body.

2) Abstract text
It is generated by a program script from the RDF description of the SKOS
Core Vocabulary. The latest version of this document can be relied upon
to reflect the current state of the SKOS Core Vocabulary.
 - is the script available? worth linking?
 - you make a claim/promise re reliability; maybe better as intent?
   and let people make up their own minds whether to trust that we'll
   keep the two docs in sync (esp as Core is going into /TR/ which is
   harder to sync, so maybe be some mismatches at least during


It is automatically generated ([src]) from the RDF/OWL description of
the SKOS Core Vocabulary. This specification is intended to provide 
the authoritative human-readable account of the vocabulary, and to 
reflect the current state of the of SKOS Core Vocabulary.

(same text occurs later in Intro; should sync those parags if edit)
3) feedback mailto:, s/comment:/SKOS-comment:/ and set subject 
in the mailto:

(perhaps the : needs escaping? works here anyway...)

4) per outcome of the SKOS Note/REC discussions, add a 
paragraph explaining our intent, and possibly the one 
I drafted re possibility of refactoring into REC-track work 
at later date?

5) en-US?

/knowledge organisation/ etc should we s/s/z/ ?

 * W3C uses U.S. English (e.g., "standardise" should read "standardize" and
"behaviour" should read "behavior").

American is the new English :)

...doesn't seem to gripe about the English speling tho.

6) OWL?
The SKOS Core Vocabulary is an application of the Resource
Description Framework (RDF).
...we also use OWL in the namespace description, albeit very slightly. 

    <rdf:type rdf:resource="&owl;InverseFunctionalProperty"/>

...is a tiny but very powerful piece of OWL to use (in describing
skos:subjectIndicator). We use it, so let's give credit to the OWL 

Suggest [[ ...(RDF) and the Web Ontology Language (OWL) ]]

7) Guide to Term Summary Tables  

URI:  	The Universal Resource Identifier.
s/The/An/ (or A? I forget my grammar ;)

'the declared range' -> 'declared range',
also same edit re 'domain', to allow for 
possiblity of multiple ranges and domains.

8) Policy Statements

The URI for the SKOS Core Vocabulary itself is:
The preferred URI for the SKOS Core Vocabulary itself is:

I think we might mean http://www.w3.org/2004/02/skos/core#
rather than http://www.w3.org/2004/02/skos/core

(and maybe we ought to say 'URI reference' instead of URI

I'd appreciate Ralph's input on this question, as it 
relates to W3C site policy.

The later text assumes without explanation the presence of the #
in composite URIs, so probably simplest to add it.

The local name of a class
The local name of a SKOS class

Meta question: if this is a first WD, do we consider these 
policy claims binding on the WG/W3C, or a statement of WG's current 
thinking? I suggest adding in a <em>Status:</em> health warning
that the entire Policy section is a best effort representation of the 
Working Group's initial thinking and intent, and that the warning
will be removed in later iterations of the document. 

Please also put in a pointer back to the overall SOTD, which remidns us
Publication as a Working Draft does not imply endorsement by the W3C
Membership. This is a draft document and may be updated, replaced or
obsoleted by other documents at any time. It is inappropriate to cite
this document as other than work in progress.

Re Changes section, note that we are moving into meta^n-process
design here, since our description of this process is governed by
W3C Process TR norms. We should be clear that 
    No substantial (meaning changing) alterations will take place.
Implementors can expect the term to persist in its current form
indefinitely. (Changes corresponding to DCMI class A may occur)

...is relativised to the WG's understanding of things. The namespace 
will revert to W3C control once this WG's charter expires; we should
be careful about the expectations we are setting. A nice big health
warning at the top of the 'Process' section should be imho enough, to
alert readers to some of the difficulties in doing this right. Sorry I 
don't have words right now...

Again, I would like Ralph's take on this. 

9) Maintainance

Responsibility for maintaining the SKOS Core Vocabulary is assumed by
the designated editors, who are at this time:

The SKOS Core Vocabulary is hosted and maintained by W3C. At the time of 
writing, W3C has delegated management of the SKOS namespace to the 
the Semantic Web Best Practices WG, whose chairs have in turn have 
delegated these responsibilities to the editors of this specification 
(Alistair Miles and Dan Brickley). The Working Group is committed to 
establishing clear expectations around the management of RDF 
vocabularies, through documentation of process and maintainance 
policy. This is itself an evolving process. Specifically, this document 
is itself situated within the W3C Process, and may change and evolve in 
the light of feedback on SKOS, and on the expectation-setting language
used to describe the processes around SKOS and the Group's view of 
the likely stability of various SKOS terms. It should be noted that 
claims made by the Working Group using the (experimental) persistence
and change terminology employed here, have as their scope the 
currently chartered Working Group. They have only draft status within
the wider W3C Process. W3C has not delegated to the WG any authority 
to make binding commitments on behalf of W3C beyond those implicit
in the formal W3C Process. 

Although the SKOS Core Vocabulary namespace document is not itself 
a W3C Technical Report, it is (at least while the Semantic Web 
Best Practices WG is charted to work on SKOS) being managed with
the intent of being consistent with this Technical Report, as well
as with other supporting materials published as W3C Technical Reports.

There may, on occasion, be periods (eg. during Web site publication)
there are minor inconsistencies between this specification and the 
SKOS Core Vocabulary RDF/OWL description. 


I dunno if that helps. I find this work incredibly hard to think about!
Very meta, re process...

There is also a parag I think might change:
The editors pledge to seek the widest possible consensus before making
any changes to the SKOS Core Vocabulary. The editors also pledge to
ensure that all development work is carried out openly and in public, in
consultation with the members of the public-esw-thes@w3.org mailing
list. This mailing list is publicly archived, and any person may
subscribe and/or post to it at any time.

I am not personally in a position to make such pledges. Something

The Working Group is committed to a public, consensus-driven 
design environment for SKOS, and to this end conducts SKOS-related
discussion in public, in particular drawing on feedback from the 
Semantic Web Interest Group mailing list public-esw-thes@w3.org .

10) 'Launch Example'

I suspect there may be Accessibility concerns (or pubrules)
w.r.t. to the 'launch example' form buttons you've used. Could these
be changed to plain hyperlinks?

11) Actual Content...

Didn't get that far ;)

Seriously, the classes/properties stuff, as far as I can tell, is ready
to go. We have open issues for the main problems that remain. 

one comment...

re Concept as "An abstract idea or notion; a unit of thought."

I think I've previously argued against 'a unit of thought', but 
failed to persuade you yet.

I can live with it for 1st WD. But I do fear it makes an 
un-necessary scientific commitment on the part of SKOS. 
Many in the Cognitive Science world don't view the process of 
thinking as being composed of discrete, nicely identified and 
atomic concepts. SKOS can be useful while remaining entirely 
neutral about how people actually think. The phrase "An 
abstract idea or notion" has similar biases, but much software.

I'd prefer "An abstract idea or notion" for now. 

12) Done :)

Everything else looks great, thanks for all your hard 
work on this! Read to go whenever you're happy, as far as 
I'm concerned, with one condition: I'd like to have Ralph's 
specific "W3C Staff Contact" OK regarding the Process/persistence/policy 
claims, as discussed above.


Received on Friday, 18 February 2005 18:33:13 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 13:32:05 UTC