is, has and alike are implied

[csarven]

To simplify the terms, consider dropping is, has or alike prefixes from properties/classes. They are in a way implied.

[stain]

-1: which one is implied, is or has? That directionality is what they are there to clarify.

[jjett]

-1

Directionality of the relationship is an important aspect to capture and so should be represented in the model.

---

Jacob Jett Research Assistant Center for Informatics Research in Science and Scholarship The Graduate School of Library and Information Science University of Illinois at Urbana-Champaign 501 E. Daniel Street, MC-493, Champaign, IL 61820-6211 USA (217) 244-2164 jjett2@illinois.edu

On Mon, Aug 24, 2015 at 6:59 AM, Sarven Capadisli notifications@github.com wrote:

To simplify the terms, consider dropping is, has or alike prefixes from properties/classes. They are in a way implied.

— Reply to this email directly or view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_w3c_web-2Dannotation_issues_70&d=AwMCaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=npggDwlZ6PziBzPBZthSo0f8iGOgRMf9ulO6o4WwfiA&m=MmwWNlb1C74ODYPK2j6FqR3V2oTigXDlRXfAzfspf9A&s=aUb7XyUO-A8iW6wyUaj1BZyH6lh3SQ9SFvVE0dlNBaI&e= .

[azaroth42]

Likewise, -1 to dropping them from the ontology. We've already dropped them in the JSON-LD context.

[csarven]

1. The directionality of 'thing has something' is obvious I think, is it not? The subject is the one with the property. Are there any inverse properties in OA?
2. Capturing the directionality is done by terms being self-descriptive (e.g., domains, ranges), not based on the human-readable string. I hope that people are not relying on what the string's are on the terms but rather their actual definitions.
3. The use of has is not consistently carried out e.g., proposed oa:text.

I'm proposing this because I find the prefix unnecessary/cumbersome, unless someone can point me at the terms in which the direction is in other way around - happy to retract in that case. Failing that, I suggest to strive for more consistency on the directionality.

Naturally, the ontology is what matters and lives on. JSON-LD context is merely on the backdrop.

[akuckartz]

:+1: because "has" and "is" are irrelevant for machines and are not necessary for humans when properties are named appropriately. These pseudo-prefixes belong to a former generation Web of Data.

[azaroth42]

We follow the Linked Data best practice of ObjectProperties being verbs/verb phrases, and nouns/noun phrases for DataProperties. So text rather than hasText, as it's a DataProperty. All of the relationships at the moment are of the form hasFoo, but inverse relationships are also likely to be useful.

The experience from other groups (such as SKOS) is that relying on definitions in specifications is the negative impact on implementations, when developers frequently have to go and check what the spec says.

[cygri]

FWIW, as @azaroth42 brought it up: The SKOS experience indicates that adjectives as property names are confusing. The SKOS experience doesn't support the view that verbs are less confusing than nouns.

[melvincarvalho]

I have seen is/has in the object oriented world, and sometimes in programming languages. Much less in ontologies, tho. I very occasionally have used is/has but agree it's probably slightly better not to.

[tcole3]

-1. Agree with Rob that it is best to follow the ObjectProperty vs. DataProperty distinction. Also, given that earlier annotation ontologies have used similar terms with different semantic meanings and sometimes with different implied directionality, I think making the directionality explicit is right way to go, even if machines don't need it.

[deiu]

+1

The is and has are definitely implied. For example, is is implied if you use an RDF type for the object (i.e. a class), whereas has is implied in all the other cases (i.e. relations).

EDIT: The game is lost the second you put the semantics in the term names. The vocabulary is responsible for proving the semantics, not the term names. For example, what if you find a really great vocabulary that is in Spanish or French, but provides English descriptions for its terms so you can actually use it?

[shepazu]

+1.

Perhaps unlike others on this thread, I consider the core data model to be more abstract than either JSON/JSON-LD or RDF. It should be a vocabulary and object structure that is informed by and can be interpreted/serialized as those constraints, but shouldn't be conflated with them.

[danbri]

The original 1999 REC had some wording that implied 'has' loosely, some template English sentence along lines of 'foo' property on x means 'the foo [property] of x'. Sorry am on a phone or would dig it out. I don't think the post 2004 RECs were so explicit but that remains the rough convention; "has" is rarely spelled out.

[azaroth42]

How about:

• hasBody --> body // make core relationships easy
• hasTarget --> target
• hasSource --> narrowerThan // directionality is critical
• motivatedBy --> motivatedBy
• annotatedBy --> annotatedBy
• serializedBy --> serializedBy
• hasSelector --> segmentedBy
• hasStyle --> styledBy
• hasScope --> scopedBy
• hasState --> retrievableBy

The State resource is a descriptor for the correct representation (and hence state) of the resource, but statedBy would clearly be very wrong. The model says:

A resource which describes how to retrieve a representation of the Source resource that is appropriate for the Annotation.

The proposed retrievableBy tries to capture this protocol notion that you can get a representation somehow, without implying that it's a URI at which you can get the representation, but alternatives are very welcome.

[tilgovi]

I don't see any problem with "state", "style", "scope", "selector" and "motivation". I don't have any idea what "narrowerThan" is supposed to mean. It's so far from comprehensible to me that even knowing what "hasSource" is I can't figure out how you got "narrowerThan". Again, "source" would seem fine to me.

I wish I could find good terms for "annotatedBy" and "serializedBy", but I'm not sure I can. Simply dropping the "by" makes it unclear whether this is about who or when or what, etc. I've toyed around with "author" and "scribe" or such things in my head, but I don't like anything I've come up with.

[csarven]

Thanks for considering and making a proposal @azaroth42 !

I have to admit that I don't quite understand the change from hasSource to narrowerThan.

segmentedBy, styledBy, scopedBy comes across as the object-influencing-subject, even though subject is making the statement. Is that expression intended?

State seems to have some overlap with dct:Distribution (via dct:distribution) and schema:MediaObject (via schema:encoding / schema:associatedMedia). IMO, hasState -> state is good. "without implying that it's a URI" for retrievableBy is not clear to me.

[csarven]

I should add that, if the possibility of the namespace changing comes down to this issue alone, I would much prefer to drop this issue altogether and live with the existing terms.

[azaroth42]

@tilgovi @csarven - The specific resource is more specific than the source resource. E.g. if the specific resource is a styled, non-rectangular segment of an image, then it is (clearly) more specific than just the image. oa:moreSpecificThan sounded worse than oa:narrowerThan (with a nod to SKOS). Verb form suggestions welcomed.

@csarven - It is intended that the object influence the subject for segmentedBy etc. The Selector instance describes how the specific resource is a segment of the source resource, the Style instance describes how the specific resource is a styled version of the source resource, and so on. The State, then describes how the specific resource is a particular state of the source resource.

The selector is not a segment of the specific resource, like the body is the body of the annotation. And thus the initial comments about directionality being important.

[tilgovi]

• "narrows"
• "specifies"

Is that what you mean by verb form?

[azaroth42]

Yep, or verb phrase like moreSpecificThan. Previously we used constrains.

[tilgovi]

I thought the goal of this issue was to call into question whether phrase constructions are necessary. What was wrong with "constrains"?

[azaroth42]

And I'm giving the reason why it is necessary... That the specific resource is more specific than (or constrains, or whatever) the full resource is critical information.

I would be happy with constrains, personally. The previous discussion was that it was confusing with constraint based programming... which (to me) is not something to worry about. @tcole3 may recall more?

[fhirsch]

The term hasSelector and the concept of selectors is much clearer than alternatives like segmentedBy

keep hasSelector !

Likewise hasSource means something, narrowerThan doesn't. Keep hasSource.

[azaroth42]

I propose that we add this to the agenda for 9/16 telco.

Overall, my position hasn't changed (-1 to dropping has from hasFoo), but wanted to propose at least a compromise to see if there was any agreement. The rationale for pushing on this now is that it would make a BIG change to the next WD if we rename everything, and use a new namespace.

[shepazu]

We have an ongoing proposal for alternate names on the wiki: https://www.w3.org/annotation/wiki/JSON_Vocabulary

If this is simply a distinction between the JSON-LD names and the RDF @context (in other words, if we're only talking about the "spec" names and not what would be used in JSON-LD), I don't have an opinion about how these are named.

If we're talking about the terms to be used in JSON-LD, I thought we had agreement long ago to remove the has/is prefaces.

[iherman]

@shepazu : my reading of this issue that this is exclusively the names in the model, i.e., RDF, and has no bearing on the JSON-LD terms. Actually, the feeling I have (but I have not checked) that the tendency is to bring some of the RDF terms closer to JSON-LD.

[tilgovi]

Oh! I have no opinion about the RDF terms, but understand some harmony would be great.

[tcole3]

Regarding constrains, another issue as I recall was concern that constrains might get confused with hasSelector, i.e.might be seen as predicate for describing the constraints that yield the SpecificResource.

Personally, I like the existing

• hasSource
• hasSelector
• hasStyle
• hasScope
• hasState because they look like a cohesive as a set, which they are since all pertain to describing SpecificResources, especially if we change hasBody and hasTarget, and I feel like directionality is useful and not altogether obvious for these predicates in the context of RDF. If we start trying to change for RDF I don't think we'll find a pattern as unifying and I think the connection to JSON-LD keys will be more challenging - but not a critical concern, just a personal preference. I understand that many do not like the has... construct these days even in RDF. The ...By construct will likely be out of fashion soon as well (if not already), but at least it puts the most important part first, but then the pattern breaks with hasSource (derivedFrom or derivativeOf are not as elegant as the ...By constructs and whelpedBy is either too earthy or too literary depending on your point of view).

I do not like segmentedBy - to me, hasSelector feels more natural for some selectors, e.g., DataPositionSelector which may yield a cell, row or column, but not something I think of as a segment, but again that may just be me.

I have no problem with hasBody --> body hasTarget --> target

motivatedBy is fine by me, but I would also be happy with motivation even in the RDF.

I don't see a good alternative for annotatedBy
serializedBy

unless you went for the longer annotatingAgent and serializingAgent, which to my ear sound even more heavyweight.

There was a lot of discussion of labels in the Community Group and prior, and I'd prefer to keep most as is unless we have need to make a JSON key totally divorced from the corresponding RDF label, and so far I think we're in pretty good shape.

-Tim Cole

[tilgovi]

I would stick with "selector" as the meaning is not so different, if at all, from what CSS calls a selector. We may have other formats and syntax, but the underlying concept of a selector being used to select part of a document is the same.

[fhirsch]

+1 to Tim Cole's comment

[[ Personally, I like the existing

hasSource hasSelector hasStyle hasScope hasState because they look like a cohesive as a set,....

.. ]]

[azaroth42]

Closing, decision not to rename for the same of renaming. (WontFix, as per Oct 2015 WD)