-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Which Tag Vocab to use? #1
Comments
I like PS Deleted comment above was an autoreply. |
After some discussion on gitter the following predicate was suggested: |
But those seem to have literals as range, so non-localizable? |
What's the intention? Terms from taxonomies or free form? A bit of both? Not I'd suggest schema:about (and refer to generally persistent URIs.. wikidata/dbpedia/dictionaries etc..) over schema:keywords. |
@csarven thanks much for reminding me of the tag: scheme. It occurred to me, I've been looking for a solution to this for about 5 years!
The examples at first blush dont seem a great fit. But I may be missing something. My particular use-case is related to tagging a URI ie a bookmark. "This bookmark is about JavaScript", "This bookmark is about Minecraft" etc. Or like a microblogging #HashTag One criticism of schema: keywords was that they are designed to be comma-separated Reading https://schema.org/about didn't seem related to tagging as described. |
Personally, I'd revive the commonTag... I prefer dereferenceable HTTP URIs for tags, as one really nice thing to do is to map your tags to other tags, so that their meaning can be inferred in some cases. Not a terribly easy choice, I admit, given all the time that has gone by, so all very IMHO, but I think commonTag had the right idea. |
@kjetilk how would that work with the commontag website down?
prefer to what ie what's an alternative?
hmm Im not easily able to visualize this. Have you used this technique in the past, or do you have a user story |
I don't find schema:keywords particularly useful (or even convenient) beyond a write-once for a human-readable case. Depending on an application's point of view, it is rather clumsy to update.. schema:about is just about categorisation in the general sense. dcterms:subject would be equally fine and useful in my opinion. Generally dereferenceable http URI would be ideal or preferable to literals. But, it still comes back to whether what's intended is more in the direction of a controlled term or free form. As you know, http URI would still make it possible to have a human-readable label that's not controlled. Melvin, I acknowledge that you are not in favour of AS2 but I'll mention it any way for the purpose of documentation in case of use to anyone else: there is There is also the Web Annotation motivation So, a lot of options. |
I suppose that we could buy the domain.... But sssh, the price might be high if interest for it is registered...
Prefer
Yeah, I implemented this for my.opera.com back in 2006 or 2007. I wrote an UI that people could use to map their tags to WordNet, which was the big structure of the day. It saw some use, but rather few used the overall RDF system in my.opera.com. What makes tags interesting are both their strengths and weakness: You don't need to have any kind of agreement around the meaning of a tag, you just make your own tag cloud, which is great, because that allows people to create a very lightweight classification, but it is also a problem, because you can't really derive much interop from it. So, finding a property that links resource and tag is nice, and I don't have a strong opinion on that, but I would like to have something more, and that something more was pretty well formulated in commonTag. |
Seems a bit like wishful thinking. Would you be willing to take on this task?
But what about a string literal? You've not mentioned how you could link a URI to a string. |
commonTag had that. |
@kjetilk Hmmm there seems to be some conflation here Perhaps it would be helpful to consider this from the perspective of an RDBMS Let's say I have a Bookmark table, which has URI, name, creator etc. I also want to add a tag to that bookmark. Let's leave aside that RDF is a set and you have multiple tags. The two design decisions are whether whether to add a tag column to the table. ie the easier way, and the question posed originally would be what to name it. That's the question looking for an answer. There is the other design approach would be to make a new table and use the tag as a foreign key. Obviously this is a more complex approach with more overheads but has extensibility benefits. That is the second conversation and we've not got a practical answer there too, because your preferred choice would be require buying a domain restarting a whole project. This might take weeks, or might never happen. What is the solution that we can use today? |
OK, it sounded like your requirement was to share meaning. If you just want to use a literal, then It doesn't necessarily mean that we need to revive the old domain, but something quite similar is needed. |
Thanks. Interesting discussion. I'm going to briefly touch on what I think is the general case of this problem, but it should probably move to another venue or issue for discussion. I'll write it out here because I think it's a way to solve this problem and others of its kind. Do we need blank predicates? In RDF a blank node is a node without a name. A debate has existed, "Do we need blank nodes?". Generally, the answer most give is yes. Let's think about why that is. Well, one reason is that a node can exist without having a name. Why? Because it hasn't been named yet. If you think about it make sense. Because we observe things, then give them a name, normally. In the same way, predicates describe relationships between two things. In the real world two things can have a relationship but not a name (aka it's complicated!). Very often the problem you have as a developer is that you know the subject and object, but you are unable to name the predicate, so we end up inevitably every so often with discussions of this kind. So, do we need blank predicates? The answer I think is No. But do we need something like it, so that we can continue to work without having to take time out to find a predicate or a name. Let me note this problem does not exist in JSON. Or indeed, other languages with variables. I would just write 'var tag' and I am done. What would be helpful for me, and maybe for others, would be a place holder so that we can work without having fully named a relationship. Just like you can work without naming a node. I know of no way to solve this general case in RDF, but it might be a useful discussion. This is why I sometimes use In any case. Thanks for the feedback. I still am unsure what predicate to finally use, but I'm closer to a solution, thanks. And indeed I don't want to derail this discussion with my use case. After all the use case is for the project pane, so let's find out what's needed there, or try to imagine it. So will track responses here. Happy to discuss further, maybe on another issue, but don't want to veer off-topic. Cheers! |
Which Tag Vocab to use?
Which tag vocab to use? I also would like something for bookmarks.
Here is a Search using LOV: https://lov.linkeddata.es/dataset/lov/terms?q=tag
Some vocabs are down
Commontag
Unfortunately commontag has been down for a while
http://commontag.org/ns#
BBC
BBC tag is down
https://www.bbc.co.uk/ontologies/tagging#terms_TagConcept
Cinelab
Cinelab is down
https://essepuntato.it/lode/owlapi/http://advene.org/ns/cinelab/ld
Tag Ontology
Tag ontology is down
http://www.holygoat.co.uk/owl/redwood/0.1/tags/tag
Possible solutions
I found commontag a bit complex. Ideal for my needs would be something like
<URI> :tag """tag""" .
There was a suggestion from around sioc topic and sioct Tag
Currently, I'm using urn:string:tag as a placeholder until there is a consensus.
So hopefully we can work out what to use
The text was updated successfully, but these errors were encountered: