Updates to exported terms

[gkellogg]

Relevant to w3c/rdf-star-wg#37, I suggest we make the following changes to defined terms:

• Change denote to reference denote in RDF12-CONCEPTS
  <dfn id="dfn-denote" data-cite="RDF12-CONCEPTS#dfn-denote" data-lt="denote" data-local-lt="denoted">denotes</dfn>
• Change denotation to reference referent in RDF12-CONCEPTS
  <dfn id="dfn-denotation" data-cite="RDF12-CONCEPTS#dfn-referent">denotation</dfn>
• Change entail to reference entailment in RDF12-CONCEPTS
  <dfn id="dfn-entail" data-cite="RDF12-CONCEPTS#dfn-entailment" data-lt="entail" data-local-lt="simple entailment|entailment">entails</dfn>
• Change equivalent to reference equivalence in RDF12-CONCEPTS
  <dfn id="dfn-equivalent" data-cite="RDF12-CONCEPTS#dfn-equivalence">equivalent</dfn>
• Change referent to reference referent in RDF12-CONCEPTS
  <dfn id="dfn-referent" data-cite="RDF12-CONCEPTS#dfn-referent">referent</dfn>

Make the following exported terms local (still referencable, but not exported to WebRef):

• extension
<dfn class="no-export lint-ignore">extension</dfn>
• identify
<dfn class="no-export lint-ignore" data-local-lt="identified">identify</dfn>
• instance with respect to
<dfn class="no-export lint-ignore">instance with respect to</dfn>
• invalid
<dfn class="no-export lint-ignore">invalid</dfn>
• merging
<dfn class="no-export lint-ignore">merging</dfn>
• merge
<dfn class="no-export lint-ignore">merge</dfn>
• monotonic
<dfn class="no-export lint-ignore">monotonic</dfn>
• rdfs1
<dfn class="no-export lint-ignore">rdfs1</dfn>
• rdfs2
<dfn class="no-export lint-ignore">rdfs2</dfn>
• rdfs3
<dfn class="no-export lint-ignore">rdfs3</dfn>
• rdfs4a
<dfn class="no-export lint-ignore">rdfs4a</dfn>
• rdfs4b
<dfn class="no-export lint-ignore">rdfs4b</dfn>
• rdfs5
<dfn class="no-export lint-ignore">rdfs5</dfn>
• rdfs6
<dfn class="no-export lint-ignore">rdfs6</dfn>
• rdfs7
<dfn class="no-export lint-ignore">rdfs7</dfn>
• rdfs8
<dfn class="no-export lint-ignore">rdfs8</dfn>
• rdfs9
<dfn class="no-export lint-ignore">rdfs9</dfn>
• rdfs10
<dfn class="no-export lint-ignore">rdfs10</dfn>
• rdfs11
<dfn class="no-export lint-ignore">rdfs11</dfn>
• rdfs12
<dfn class="no-export lint-ignore">rdfs12</dfn>
• rdfs13
<dfn class="no-export lint-ignore">rdfs13</dfn>
• D-satisfiable
<dfn class="no-export lint-ignore">D-satisfiable</dfn>
• satisfiable recognizing D
<dfn class="no-export lint-ignore">satisfiable recognizing D</dfn>
• Skolemization
<dfn class="no-export lint-ignore">Skolemization</dfn>
• standardize
<dfn class="no-export lint-ignore">standardize</dfn>
• D-unsatisfiable
<dfn class="no-export lint-ignore" data-lt="D-unsatisfiability">D-unsatisfiable</dfn>

[pfps]

Is this an enhancement or is it just editorial?

[gkellogg]

I suppose that's a matter of opinion. You might know better how important advertising these terms is outside of the spec itself. It should not break any existing links into the specification, but for the first five terms flowing the link will take you to RDF Concepts rather than the location of the "definition" in RDF semantics. Alternatively, these could be made internal ("no-export") terms like the others, but there should probably be text added to reference the exported term from RDF Concepts.

My purpose was to note that we have terms defined in parallel or that we have terms we might not really want to export.

[pfps]

I think that most or all of these are just editorial changes.

Is there a document that describes what the arguments to dfn mean?

[gkellogg]

I can create a PR do handle this.

The ReSpec Wiki documents the attributes (for the most part), but there is a certain amount of experience and trial-and-error involved in figuring these out.

[pfps]

That would be useful. Can you create a PR for the local-only ones by themselves? They all seem to be purely editorial and non-controversial.

I think it would be a good idea to collapse the terminology in semantics to use only denotes and referent and to check what the situation in concepts is. As long as no anchors are lost this would be a non-controversial editorial change. I'll put together a PR for this. Then a final PR can do the first five changes.

[gkellogg]

That would be useful. Can you create a PR for the local-only ones by themselves? They all seem to be purely editorial and non-controversial.

I can split #17 between the "no-export" and the data-cite changes.

I think it would be a good idea to collapse the terminology in semantics to use only denotes and referent and to check what the situation in concepts is. As long as no anchors are lost this would be a non-controversial editorial change. I'll put together a PR for this. Then a final PR can do the first five changes.

If you add data-lt (or data-lt-local) to a definition, you can use that as the body of an anchor and it will automatically reference the single definition. For example, this is already the case for "simple interpretation" and "simply entail".

<dfn data-lt="simply entail">simple interpretation</dfn>

That could be done for denotes and refers to for example:

The words <dfn id="dfn-denote" data-cite="RDF12-CONCEPTS#dfn-denote" data-lt="denote|refers to" data-local-lt="denoted">denotes</dfn>
      and <a>refers to<a>

Although, in this case, they both reference denote in RDF Concepts. It does allow you to simply use <a>denote</a> and <a>refers to</a> in the body of the document.

[pfps]

No, leave #17 as is. I'll update my PR after #17 is merged in.

The problem with using both denotes and refers to is that people end up thinking that they are different, even with the disclaimer near the beginning. Using one term removes this problem. Also, refer is used in a non-technical sense in a few places in Semantics so it is a good idea to not use in a technical sense.

Of course, this is all just wording changes and thus editorial.

[gkellogg]

Note, to be particularly safe, it's possible that there are existing links into #dfn-refers-to, so a pattern I've used to preserve the entry point is to add <span id="dfn-refers-to"></span> near the definition of denote`. It's a pain to manage manually, but it makes sure that any inbound links for deprecated terms still go to the right place.