Changing the name of the "Specific Resource" to something simpler?

[iherman]

The term "Specific Resource" is important in the Web Annotation Model but, for this document, the name is fairly "meaningless". Maybe we should find a simpler term?

[iherman]

I was wondering about "Selection". That seems to describe what we are talking about in this context.

We can extend the WA ontology on /ns to declare Selection and equivalent class to Specific Resource, to avoid problems in RDF land; that would not create any problems with existing WA implementations.

/Cc @azaroth42

[azaroth42]

What about just creating a different JSON-LD context that defines:

"Selection": {"@id": "oa:SpecificResource", "@type": "@id"}

?

[azaroth42]

That said, I think this is an anti-pattern, and has bitten us pretty hard in the past when the use cases expand. I would recommend against it, personally.

[iherman]

At the moment, we do not even talk about JSON-LD in this spec. "Just" JSON. In other words, There isn't any JSON-LD context (let alone RDF).

What kind of use cases do you envisage where this would byte us?

[azaroth42]

If there's no RDF, then what's the requirement to add it into the RDF namespace?

[iherman]

No requirement. Just to avoid confusions if one looks at both the WA and this document.

[iherman]

B.t.w., I missed the obvious name to use (I know, it is a bit of a bike-shedding): "Locator". After all, that is the title of the document...

[tcole3]

Regarding terminology: I would prefer that this document extend the Web Annotation SpecificResource model rather than create a model that is in conflict. So I am not sure the benefit of a simpler term is useful unless it is clearly a different thing. This may be the case if our use cases really require us to identify locations in resources as well as fragments or segments of a resource (aka SpecificResource), since SpecificResource seems a poor name for a location in a Web Publication But we need to settle whether use cases require that we extend to talking about locations (e.g., between character X and character Y) and not just fragments.

With regard to RDF and context document, I see no problem with including as an appendix to this document a context document (stand-alone or supplemental to the WA context document) for those who want to treat the json as json-ld, even if we reduce the verbiage in the tables and elsewhere about RDF (see #7). Especially if just a non-normative appendix this does no harm that I can see. Again, ideally, json-ld created in accord with the WA model should be valid according to this document, so for that reason I would like this model mappable to RDF and consistent with WA model for same keys. Otherwise we will lose interoperability between those who choose to annotate Web Publications using the WA model and those who choose to bookmark using this document. (JSON is nice in that non json-ld apps will simply ignore any context keys encountered.)

[iherman]

@tcole3,

I obviously agree with your concerns, but I think we are all right. Indeed, the current text uses the term "Locator" (as an alias to a "Specific Resource") as a term in the text only. It does not appear in the JSON structures and their requirements. There is no requirement (nor should there be) to have a type property set to SpecificResource; the RDF semantics, combined with the domain specification for source and state should be enough (from an RDF point of view). What this means is that any "Locator" object in the sense of this document is a valid WA model object if the @context is used. In other words, the only thing we are changing is the human facing naming. Which should be fine, and we would not even need to change anything in the WA @context file.

---

Two things, though, to add:

1. It may be worth adding to the document something like a Locator implementation should ignore any JSON term that may appear in an input and not described in this document. That is usual JSON practice, but it also means that Locator implementations may receive WA objects without further ado.
2. I looked at the WA Vocabulary for, say, state, and I realized that the domain for the property is a Class called ResourceSelection which, in its own specification, which is a superClass of SpecificResources (per the definition of the latter). I am not absolutely sure why this model is used in WA (I would have expected the opposite, ie, that SpecificResource would be the superclass of ResourceSelection). But, in light of this, we could also decide to call that object, in this document, Resource Selection instead of Locator, which would put it closer to the WA model, and uses terms that are, in fact, close to our usual terminology. (In which case we may want to change the document's title.)

[iherman]

With the merging of PR #14 this issue can now be closed.