Bogus property as:id

[tpluscode]

Please Indicate One:

• [x] Editorial
• [ ] Question
• [x] Feedback
• [ ] Blocking Issue
• [x] Non-Blocking Issue

Please Describe the Issue:

The RDF vocabulary of Activity Stream includes a property http://www.w3.org/ns/activitystreams#id. By looking at the spec it seems to represent a mapping to JSON-LD's @id keyword much like as:type does.

However, it has no place in the RDF vocabulary.

<http://www.w3.org/ns/activitystreams#id> a owl:DatatypeProperty,
        owl:DeprecatedProperty,
        owl:FunctionalProperty ;
    rdfs:label "id"@en ;
    rdfs:domain [ a owl:Class ;
            owl:unionOf ( <http://www.w3.org/ns/activitystreams#Link> <http://www.w3.org/ns/activitystreams#Object> ) ] ;
    rdfs:range xsd:anyURI .

Described as above, it does not make sense. The @id field in a JSON-LD document is only a syntactic feature to represent given resource's identity. It is by no means a property of that resource. Thus, is does not represent a predicate.

Not to mention the rdfs:range xsd:anyURI which would indicate a string literal, where the ID of a resource would in fact be an actual Named Node URI, or... blank node.

Please remove this from the vocabulary

[nightpool]

Our OWL schema is non-normative and best-effort, and not maintained by the working group. The normative reference for the id and type aliases is https://www.w3.org/TR/activitystreams-vocabulary/#dfn-id (also, I believe referring to them as http://www.w3.org/ns/activitystreams#id and http://www.w3.org/ns/activitystreams#type is technically incorrect? since the JSON-LD schema defines them as aliases of pieces of core syntax, not URIs in their own right, as you mention)

[tpluscode]

Our OWL schema is non-normative and best-effort, and not maintained by the working group.

It's not generated automatically in any way? A PR is welcome then?

---

In the case of type, you could get away with mapping it to rdf:type. This is pretty much what JSON-LD's @type keyword represents. It is still only JSON-LD-specific syntactic construct. Like a in turtle's <foo> a <bar> notation.

Bottom line, yes, I would not refer to either id or type as URIs, much less from the as: namespace

[evanp]

We included the mapping of id to @id and type to @type for backwards-compatibility reasons with Activity Streams 1.0. I think there may be other reasons it was included, but they're not immediately at hand. I'll see what I can do to dig up the justification.

However, these two properties are '''widely''' implemented in a number of processors, and removing or deprecating them would be a big problem for a large number of implementers. Unless there's a better case for removing or deprecating them than conceptual purity, I would prefer that they remain.