TPAC Breakout on Vocabulary Management

<scribe> scribenick: rhiaro

phila: Good afternoon! *intro*
... My role is data related things at w3c
... An issue that is coming up again and again is that the w3c is bad at managing vocabularies, at helping people develop them, at helping people maintain them
... the reason we're bad at it is because our process is designed for rock solid specs that we can prove work, that you can build businesses against
... We're good at that. But not very good when you want to have lots of changing situations and people contributing in an agile way
... So we need a different approach. Some of the baggage of not changing a byte gets in the way
... I'd like to focus on one mini issue that will raise discussion points that speak to the bigger issue

https://www.w3.org/2016/08/namespaces/

scribe: The mini issue is that LDP was finished, and then the SocialWG find that in some of their work they want to add one term to the LDP namespace
... Does anyone think they shouldn't?

danbri: When people die they leave a will. When WGs die they don't really express their hopes and dreams for what comes after
... If it was OWL, these are fragile technologies, it can break... if you know the expecations the group had set, then sure. But you can break things by adding stuff to RDF. You can introduce contradictions.

sandro: Fortunately, WGs are not people. So all the people in the OWL WG are still alive, and so are LDP
... So it's quite possible to contact them and ask their opinion and see if they can see a problem

danbri: Generally I'm in favour of agility, but don't assume that adding stuff does no harm
... It can introduce confusion

tantek: why is it that adding is blocked by default?

cwebber2: Functional programmers also hate it when things change... but are okay with append-only data structures
... Seems like a tremendously differnet thing than modifying something that does exist
... Maybe a group should be able to say this is our baby never touch it, so there should be some sort of process so we don't just add spaghetti
... I don't see the problem in appending things if people say they're okay

danbri: Documentation needed so undermining existing terms doesn't happen
... that's happened in schema.org
... People don't realise until a few weeks or a month later
... How can we tweak the definitions after the fact

David: The SW was not designed for top level vocab alignment... no-one ever thought that the whole thing we're tyring to do with LD/SW was to create vocabularies that must be considered in the totality of every other vocabulary

danbri: within the single ns

David: schema.org is a big ns..

danbri: Dublin Core has close terms

sandro: Absolutely those ar eissues. What is the bar that should be set?
... At the very leaste, all the people who were invnolved in the design before can say yes, it would make sense. I think that would be too high a bar.
... If the chairs and editors can see that it's okay..

phila: So in https://www.w3.org/2016/08/namespaces/ we have a speciifc set of propopsals on that
... Yes it is possible that one group could create a rec track doc that is attached ot a ns, and someone comes along and just adds to it who doesn't know anything about it... yes that could mess things up
... We think we could get round that by some sort of discussion
... if you decide, as a WG, that you want to add one term to an existing ns that came out of a WG that no longer exists
... What they first do is contact a special mailing list (we have to work out who answers this)
... And you don't just add it. You have to give a reason why. Describe the term, why it is appropriate to add it to the existing ns
... Evidence that any relevant group sand communites which initiated or use the ns have been contacted to determine if there is any principled reason not to add them... there is outreach

<tantek> /me wonders how can you tell who is using your ns?

phila: And then link to your own document, which is defining your term
... If we go through the process of contacting the relevant people, and given there is salways someone somewhere that is writing some code, but you make a concerted effort
... Does anyone think it's a bad idea?

raphael: in the case where vocabs are part of rec trac, generally you may have test cases that try to use all terms defined in a vocab, how do you work that?

sandro: outside of OWL-DL I can't see anything that would actually pay attention all terms int he vocab. OWL-DL wouldn't even notice that
... A vocabulary is not the same as a ns document
... The spec says here are the URIs you care about. The ns document lets you dereference them. If there are other things in the ns document that's irrelevent
... If you put a contradictory rdf statement in there that will cause a problem for some reasoners, but just defininig the term, I don't think so

kerry: are you implying you have something in the ns document that isn't in the spec?

phila: it's normal..
... This for example is the CSVW
... This is not the TR space rec trac, this is just the ns with a list of what is available in this ns
... Adding a term to this document, which is what we're talking about, wouldn't make any difference at all, wouldn't edit, the CSV on the web standards
... But what we're saying is *before* you go messing with that, you need to contact the CSV on the web people
... We're not talking about editing standards to add something new
... We're talking about adding a term to a ns document which is not a standard, having checked and so on

sandro: the RDF spec is 12 different spec. THe RDF ns is gathering together these terms
... There are already these pointers back and forth

David: if this was done properly it might provide the beginning of a process to fix things like having stuff scattered over 12 specs, and we don't have a mechanism for saying that now all this work is done and the WG is finished, ther'es no mechanism to just say let's have a look at the totality of the specs and put together something akin to a ns

sandro: RDF is split across 2 namespaces

danbri: Changing URIs is even more expensive
... My only concern with this added petition thing is that there's this built in bias towards fragmentation... you don't need to add if you can change (?)

timbl: There's a WG that has produced one vocab with 16 terms. THen another WG thinks the stuff we've produced, our terms would fit in the first group, let's propose it to them
... it's an addition, it adds more text, more data
... if you could change the spec it would be an addition to the spec as well. One part would be to say we propose a change to the spec itself. One is to make it easier by going through a social process with the original WG which may involve someone stand in if they don't exist, the result is just nice.
... All the things with the same sort of semantics, can be assembled in the same sort of ns, that's very nice, better for developrs, don't have to mess around with many prefixes
... Suggesting changes or deprecating other people's things is not so good..
... The other thing, is addin ginformation, to say by the way foaf ontology, we the vcard ontology think our name is the same as your name, and we'd like you to add that equivalence. Just adding a fact.

cwebber: I'm not sure about updating old namespaces to move terms. That's not my concern. I'm concerned about new and upcoming namespaces
... The decision around this will affect what ActivityPub does. We know we have certain terms we need. I'm anticipating, social networks are complicated things, we'll miss some things the first time..
... We might want to add some stuff. I'm looking at right now... should we do it with w3c or should we go to w3id.org?
... The updating old things I can understand why that might make some people uncmofrotable. But for new things, groups shoulld be able to opt into this
... That is an easy win, right?

Armin: If we're allowed to add new terms, would it be nice to have a living documetn which is automatically updated?

phila: You're getting onto my big topic... that's about tooling, managmeent overall... would like to test the water, but Dan and I are running a session about that on friday

sandro: nobody would disagree with that, that' sjust a resource question
... do we have consensus about adding new terms..?

phila: if you take the effort to contact people

sandro: and document everything

<sandro> PROPOSED: https://www.w3.org/2016/08/namespaces/#new-namespaces

<Zakim> raphael, you wanted to talk about social contract around a vocab

<csarven> +1

<david_wood> +1

<sandro> +1

<cwebber2> +1

raphael: adding new things not a big deal. When a vocab is designed, there might be already a social contract on which terms we have or do not have. So imagine the SSN onotlogy they want to add a term, but in the lifetime of the group there is a decision that we don't include it

<tantek> +0 seems reasonable, weak opinion

raphael: And 3 months later, the same guy who was a minority wants to add new term
... Adding a new term is not that innocent

+1

phila: If you have a term of 'agent', and add a new term of 'person' are all your agent things wrong suddnely? Yes, it isn't always cost-free. Hence youv'e gotta check with people, not just do it.

raphael: how long do you give them to anser?

sandro: silence does not imply consent

<tantek> where is the guidance on whether to add a term or make a new ns?

sandro: When you need horizontal review..

raphael: the text doesn't say that if there is no answer then the term is not added

phila: requests will typically be responded to within two business days

sandro: that's request to the team, not for review

<nandana> +0, agrees with raphael. At some cases the WG might've left those to keep their vocab simple enough and adding more terms might contradict with this.

danbri: do you distinguish adding a term to adding assertions about a term?
... there are a bundle of things you'd say at the same time as sticking a term in

phila: which is why we can't cover everything, but say do due diligence

danbri: it's framed as adding a term, but need description

phila: requires description

<tantek> danbri gives example of adding "Palestine" to the "Country" namespace

<tantek> (or Taiwan for that matter)

timbl: a whole subsection of this can be just adding translations

csarven: If we look at human languages and dictionaries and how they work... whether rdf vocabs should reflect that. Any term, besides new terms being added, but existing terms get different definitions over time. Somehow that works.
... You got to read a description o fthat term and you see different verisons o fit

timbl: the RDF philosphy is not the philosophy of natural language
... We constrcut it. We are engineering... we construct a use case, and RDF terms are owned by the person who owns that domain name
... They're the authority

<david_wood> timbl: "We are philosophical engineers"

ericp: The reason we do all this vocab management stuff is because natural language does not work :p

timbl: this is a rathole

george: date entered into the vocabulary should be present

phila: that's reasonable

<raphael> +1 to George's proposal

<ahaller2> +1 to george

phila: That suggests that the original vocabulary would hopefully have metadata that tells you when it was created and when it was updated.
... When you add a new term, it should include when that was added

<cwebber2> yes also +1

<rhiaro> +1 to george

<cwebber2> that seems good/easy

timbl: most of the ontologies have not worked like that so far. We switch it and say at the top this is living and say you can't assume the date of each term is the date on the document

phila: I don't want to stand here reading text out... making sure each term, it must link to where it's defined
... Modification and removal now
... We've been talking about adding. It's going to be easy to say a new WG should NOT remove a term
... Can a new group modify the semantics in any way? Tighter, looser, clarification? (With consultation)

sandro: I'm gonna say the answer is the same as the rest of w3c... the fact that it's a ns doesn't matter. The ns reflects the recommendation. Recs can change previous recs occasionally, with a whole lot of review
... I don't see why this is any different

timbl: People make mistakes..

jeremy: The way that I"ve manged these kind of things is it's aboslutely forbidden to tighten a definition. You could in good circumstances widen the definiton, because it sitll includes the way it was used before

kerry: what concerns me about any of those is a strong sense is a lack of any real governance. There's a lot of governance associated with deprecating a standard

sandro: My strawman proposal is the ns is the same as the document. TO change a rec you need a fully chartered WG with a charter. To modify

kerry: My concern is broader... contact some people who were involved... pretty much anyone can do it, from reading that.. for adding a term
... strikes me as way too easy to have governance over

arnaud: sounds reasonable but the problem is, it starts to replicate an issue with specs we have today for which we have no wg around, in data shapes we found a bug in sparql, we don't know what to do try to get the community to agree on a fix, but even if we get that we don't know how to use it
... I would hate to replicate this... the process that is 'just charter another WG to revise sparql'...

sandro: errata

phila: I propose we charter a WG for one meeting at TPAC... go through all the stuff that's wrong and resolve it.. anyway

timbl: why don't we do all the outstanding bugs in the recs before we leave today?

*laughter*

danbri: not all namespaces are rdf namespaces
... OWL is a speical case of RDf. There are others that might have format/standard specific...

sandro: this is just about rdf ns

danbri: I'm not sold on the loosening and tightening are different. You can still break things.
... If you write code assuming one and it was changed to be the other, things leak through

timbl: in solid we decided we're going to use vcard, the way it works is it says I have a friend and you are of type Friend
... it's broken in RDF, it doesn't talk about relationship
... Pretty soon you are mentor, father son, and all these things, it's not helpful
... It's modelling less

danbri: I'm not intrinsincally an ArchNemesis

timbl: that is a whoops..
... There's an example of something where the stability of vcard is very important, but ther's a chunk which ishorrible
... Should we fix it?
... Should we suggest that people use vcard the good bits, and make their own separate ontology to do relationships?
... What should we do?

phila: that sounds like an application profile
... you produce something encoded in shacl... say which to use... if you want to say this, you say don't use vcard
... tells peopel how you should use vocabularies
... Defining a vocab is all well and good, but doesn't say how to use it

timbl: the issue is that anyone who does try to use it will make strange consequences

ericp: Ther'es tim's example which illustrates the meta level, what is the streamlined process by which we can reach out to the right people, that we've been reasonably careful and not broken existing data

phila: how do you prove that you've asked all the people you need to ask

<david_wood> deiu, the problem is most of the people speaking aren't on IRC.

sandro: says boldly that silence is not consensus..

ericp: there's a really vague thing for TR-PR you have to show evidence of wide review. That's goign to be spec specific... we haven't been able to get tighter than that
... You can't codify that, all you can do is leave it to director discretion

tantek: with my AB hat on I thought I heard arnaud... correct me if I'm wrong... if a ns document is a normative part of a rec

sandro & phila: it never is

sandro: you could make it an appendix, but normally it's generated by hand or by machine from the text of the specification
... Somebody looks at the spec and makes it

tantek: I'm having trouble reconciling interoperating.....

sandro: that's not..

timbl: timeout, I use namespaces for interop all the time. What you put in them really matters
... If you put stupid labels that are not good you making the world a worse place
... So some people put labels in lots of languages is really neat

sandro: that doesn't change whether the software using the vocab does not interoperate

tantek: if it's a normative rference, if you're going to add or change it, that's equivalent to proposing recommendation type stuff..

timbl: it's good practice to generate the ns document from the human readable document or the other way round. Dan you've done that with lots of things?

danbri: we did a lot of things before rdfa... we used to use an rdf/xml file and generate xml
... if we started from scratch it'd be rdfa now

tantek: the example use case you started with ..

phila: This is not a normative document. The normative document is /TR/

tantek: has a normative reference?

phila: no

sandro: this is the machine or hand generated summary

tantek: how is that not normative?

<danbri> reminded of https://www.w3.org/DesignIssues/NamespacesAreResources.html

raphael: In the rec trac doc of Annotation, with json-ld context, if you add new terms you'd need to update json-ld context

tantek: the bottom line is you're altering the IP footprint and that implies requiring an AC exclusion opportunity [like Proposed Edited Recommendation]

phila: I don't think you are

sandro: json-ld raises a different question

cwebber: I think json-ld context might be a little bit more complicated.. if you include a context and you add a term to it ... eg. overlapping terms with multiple namespaces? Something else globs on that wasn't there before?

ericp: the last one wins in JSON

danbri: we ran into this in schema.org. If you have a huge verbose context file that declares every term, it's okay. If you want a tight thing you get the problem

timbl: the import * problem

phila: this specific case in point... this is the LDP ns document not the recommendation. It links to the normative document

<csarven> https://github.com/csarven/ldn/issues/13 <-- ldp:inbox

phila: want to add 'inbox' to this
... I hear a number of reasons why the generic policy might be dangerous
... kerry says governance is loose, tantek says IP concerns..
... how do we align that with the fact that the LDP group think that adding inbox here is a totally fine and sane things to do

csarven: this case is filling a gap that was intentionally left

david: that gap was left not by design but as a tool to get around a lack of consensus, is my recollection

sandro: in ldp we had a logn wishlist of things we weanted to do in the future, which we haven't done yet
... Were they all going to be in 30 different namespaces?

<tantek> ^^^ that was my original question above

sandro: Really if you're saying 30 then you can object to this proposal, but otherwise you have to let future work extend the ns in the ns

<tantek> what is the guidance on adding to a NS vs adding a new NS?

<danbri> I suspect the process quirk of namespace docs being outside the Process stems from https://lists.w3.org/Archives/Public/xml-uri/2000May/0000.html - i.e. when many in XML community didn't want namespaces to be resolvable to documents at all.

david: speaking as an implementor of the ldp spec... I'd rather update my implementation than live with a dead spec
... Not everybody is going to feel that way

sandro: I'm not sure that's the tradeoff

arnaud: the quesiton is, would you rather add another namespace if it gets revised

david: no I wouldn't, I'd rather go into one

<tantek> I'm not sure the process folks would be happy with the use of namespace additions as a loophole for adding feature(s) post-REC

david: I'm not sure the LDP example is as clean as it looks. As I recall the discussion around container, you'd be changing (crrect me if I'm wrong) the intention of the WG

various: ?

david: defining a method for discovering a container

timbl: which doesn't currently exist

david: the group didn't do that because they didnt' get consensus

ericp: I'm going to say that's fine.
... Someone is coming along and cleaning up laundry. The fact that I group had arrived at a stalemate and couldn't resolve a problem..

david: so we sneak it in later?

ericp: THat's fine.. you can even conspire to do that

sandro: Every WG I"ve ever seen does that
... They say we're not going to settle this now, this is for future work. probably won't be a w3c rec
... That's the only way you can ever finish a WG
... YOu're not making it par tof the Rec

timbl: if they didn't get there, there must have been some issues that are tough

various: people are might have explicitly objected

<danbri> +1 to tantek's "I'm not sure the process folks would be happy with the use of namespace additions as a loophole for adding feature(s) post-REC"

csarven: I don't think it' suseful to speculate about the exact reasons something was not added. The point is it was not, and in light of new information in the future, a new group reconsidered that information and came to a different conclusion, and it now makes sense, we have new use cases, we foudn we were not able to build stuff that we need it for, so we can add it

<danbri> It's all about expectation setting (and documentating of same). If a WG defines a ns as closed/static/conservative, better to respect their wishes; if they define it as wiki-like and open to subsequent interference/improvement, sure great fine.

timbl: there are two ways to go ahead and do that - one is to change the original spec, and make a version of it and make that change
... The other thing to do is to say the way these namespace documents arrive is as an administrative duty of w3c staff to amke sure there is machine readable data at their urls, which points to the appropraite spec
... in the sitaution wher eyou have two specs which document the same namespace, it's reasonable to make a second spec which defines the new term
... You have two tr documents, one is old and hasnt' changed, a new one hasn't changed
... THe staff create the ns document and add pointers to both specs

ericp: One minor point. I was sort of promoting the last person standing wins argument... my concern is that you don't want to have situation where everybody is afraid to do something because they dont' want to dig the whole record of the group
... You should leave breadcrumbs when you decide NOT to do something because it's wise, you can record notes for future generations
... or be aware of these issues

sandro: yeah put it in the ns document..

timbl: you can say something is NOT an rdf:Property

phila: I don't think we've reached a full consensus on this. I thought we would. But given what we've heard, who things we should not add inbox to ldp?
... Bearing in mind the precedent

<tantek> now I'm a -0 due to the process / AC-exclusion opportunity problem

nandana: I don't object, but if you're not involve din LDP or SWWG you probably dont' care

arnaud: there is still an ldp public mailing list
... as a good gesture, send an email there

david: I would love to say yes to this, but I am worried about the precedent of if you can't get somethign done in a group then get a better group

sandro: is anybody objecting?

ericp: this is one fo th eplaces in the critical path

phila: who thinks the discussion we've heard means we shouldn't do it for now
... who doesn't have enough information
... Thank you for your complete lack of cooperation there.

<raphael> -0 and abstain for the precedent

phila: I don't think we have consensus

<danbri> I do solemnly declare that I know not of any lawful impediment why [term, definition] may not be added to [namespace, version, checksum].

timbl: rephrasing the question... you can object or you can not object. We are not in a positon to say yes.

phila: does anyone objec tto adding inbox to LDP?

room: no

phila: does anybody object to the precedent

room: silence

<csarven> room claps