Re: Namespace persistence etc

(excuse the belatedness of this reply, I thought I had responded but
don't see it in the thread)

On 13 July 2016 at 06:12, Phil Archer <phila@w3.org> wrote:
> @Scott - please chime in with any variance to this from an OGC perspective.
>
> Dear all,
>
> I must begin by apologising for not being on the SSN call today/last night.
> I could make up some convoluted reason but the truth is that I forgot.
>
> I know one of the topics discussed was the issue around vocabulary term
> persistence so I should set out a few things about that.
>
> The principle is, I think, straightforward: any change made to a vocabulary
> shouldn't break existing implementations. Since we don't know who has an
> implementation, we can't write to everyone and ask "if we change this will
> your thing break?" Therefore we have to be cautious.

We discussed this a bit further f2f last time. If you want to be this
strict you will literally only be allowing yourself meaningless
changes to a term's definition. For example, if you change the case,
spelling, indentation, punctuation, phrasing order or other minor
aspects of the rdfs:comment of a type or property, you're not
affecting 1.) for a type, the things that are in it 2.) for a
property, the pairs of things that it relates. As soon as you start
tweaking the text to clarify meaning, you affect 1.) or 2.), and these
can always potentially create breakage. The notion that some changes
are broadening and some are restricting does not affect whether those
changes might break things; all that is needed for potential breakage
is any change from previous conditions. Software and applications can
be very fragile, and embody all kinds of assumptions.

Consider the example of Course markup, and a CourseInstance type with
a courseMode property. Imagine version one of the definition gave
"face-to-face" as a (text or URL-based) value option for that
property. A later revision might want to clarify whether Skype
sessions (or VR or whatever) counted as face-to-face. Prior to that
clarification applications could have assumed it did, or that it
didn't; there's always the risk of breakage even with modest
improvements. This is not a radical change in meaning, but can make
the difference between something working as intended and not. It is
also not a theoretical example but comes from Google's review of the
draft Courses schema,
https://www.w3.org/community/schema-course-extend/wiki/Mode_of_study_or_delivery

> That's what leads to W3C saying that vocabulary terms may not be deleted or
> their semantics changed radically. But it only applies at the namespace
> level. If you have a new namespace, you can do what you like since nothing
> will break. *However* it's going to be really confusing if some terms in the
> old and new namespaces are the same but with radically different semantics.
> So my interpretation is:
>
> Same namespace:
> ===============
> No deletions.
> No changing or tightening or semantics (i.e. don't add a new domain or range

FWIW the approach we took at schema.org was to use weaker domain-like
and range-like properties that give us more wiggle-room
(domainIncludes, rangeIncludes). It is a kind of promise that things
might continue evolving.

You mention tightening and (later) weakening. What about clarifying?
Realizing that definitions were not as tight as originally hoped is a
hugely important class of schema edit.

> - make a sub class|property and put the new restrictions on that)
> Deprecation is OK.
> Loosening semantics is OK (so you *can* remove a domain or range restriction

This can also cause breakage, if downstream clients expect the data to
already embody those restrictions. There are also restrictions that
are not embodied in domain/range but are carried in the textual
definitions.

> since it is extremely unlikely that doing so will break anyone's existing
> implementation).
> Adding new terms is fine.
> Clarifying existing definitions is OK.
> Adding new translations of labels is expressly encouraged.
+1
>
> Different namespace
> ===================
> We can be a little more relaxed here. Recall that documents on w3.org are
> persistent so the original documentation will always be there (at the
> original URI or redirected from it).
>
> No need to replicate the whole of the old vocabulary, so no need to include
> deprecated terms - they are deprecated by not being included in the new
> namespace.
>
> Assuming the vocabulary has the same name then terms that appear in both old
> and new should broadly be the same although semantics can change a little.
> It's a matter of judgement.
>
> The case I keep in mind is Dublin Core/DC Terms. dc:creator took either text
> or a URI as a value - which was confusing. dcterms:creator should take a
> URI.

Minor nitpic, DC doesn't say quite that. See
http://dublincore.org/documents/2012/06/14/dcmi-terms/?v=terms#terms-creator
It says that the value of a dcterms:creator property will be a
dcterms:Agent. For which see
http://dublincore.org/documents/2012/06/14/dcmi-terms/?v=terms#Agent
"A resource that acts or has the power to act.", "
Examples of Agent include person, organization, and software agent.".

So (in json-ld) you could have something like,

 {
   "...": "......",
   "dcterms:creator":
    {
      "@type": "dcterms:Agent",
      "foo": "bar", ....
    }
  }

There are those in the Linked Data community who take the view that
every time you mention an entity you should give a URI for it, but
that viewpoint is not currently baked into DC Terms. All that DC Terms
says is that a creator is something that can act, which is pretty
broad. But it does as you point out discourage us from using names of
those things as values for the property.

cheers,

Dan


> Hope this helps clarify things.
>
> Phil.
>
> --
>
>
> Phil Archer
> W3C Data Activity Lead
> http://www.w3.org/2013/data/
>
> http://philarcher.org
> +44 (0)7887 767755
> @philarcher1
>

Received on Wednesday, 24 August 2016 09:15:27 UTC